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I. INTRODUCTION 


A. BACKGROUND 

Computer technologies continue to evolve along a variety of paths, each with an 
accompanying set of advantages and disadvantages. Typically, the primary design goal 
in the development of new, superior computer is to achieve processing performance 
beyond what is currently available in a given cost range. The speed with which the 
assigned task is accomplished is a key measure of a computer’s ability. 

1. Single High Speed Processor 

One path toward this goal concentrates efforts on improving the abilities of an 

individual processor: the device at the heart of most computers. Vast improvements have 
been realized in improving the processor architecture and shrinking the dimensions of the 
components to reduce the time needed to physically move control and data signals from 
one point to another within the processor. Even electrons moving at near the speed of 
light require a finite time to travel finite distances, thus imposing an upper bound upon 
maximum obtainable performance. More improvements in this approach will no doubt 
occur, however, they will be realized with ever greater expense for each small increase of 
processing speed. 

2. Multiple Processors Using A Shared Bus 

Another approach involves dividing the task among multiple processors, each 

assigned a portion of the task. This allows processing of different pieces of the task to 
occur simultaneously or in parallel. Ideally, the time required to complete a given task 
that is divided in such a manner should decrease proportionally with the number of 


processors assigned. That is, doubling the number of processors should result in reducing 


the time required to complete a given task by half. In practice, however, the addition of 
processors does not result in linear performance improvements since each task will 
always contain some portion which must be executed sequentially, thus voiding the 
parallel processing capability available. Amdahl (Ref. 1] explained that this occurrence 
places an upper limit on potential gains made in parallel processing, regardless of the 
number of processors used. This paper assumes, however, that a given task can be 
divided sufficiently to warrant a large degree of parallel processing. 

Another obstacle exists preventing parallel machines from achieving maximum 
potential performance gains. Processors working in parallel will need to share data as the 
processing proceeds. This sharing of resources among many processors leads again to 
the problem of stretching the capabilities of individual components. In this situation, the 
common data path and common memory storage devices will become a performance 
restriction as the number of processors involved is increased [Ref. 2:p. 5]. Greater 
advances in processor technologies over bus and backplane technologies further 
exacerbates this problem, since by adding faster processors to a given balanced 
multiprocessor bus, the bus will become overloaded and hence slow the entire system. 

3. Multiple Processors Using Point-To-Point Communications 

To avoid the potential bottlenecks associated with having all processors sharing 
a common communication resource, processors can communicate more directly using 
distributed connections, that is, each processor has its own finite set of independent 
connecuons. As the number of nodes in a network grows, however, a point is reached in 
which all pairs of processors will no longer be directly connected. The transport 
mechanisms used for data communications and which must deal with these problems can 


be classified into two broad categones: packet switching and circuit switching. 


a. Packet Switching 
In a large network where all points cannot directly communicate, the 
connection must be completed through intermediaries. This is known as packet switch- 
ing or packet routing. Data is carved into blocks of convenient size and passed with 
routing information from node to node until the desired destination is reached. Packet 
routing is used extensively in hypercube architecture computers which are a network of 
processors symmetrically interconnected so as to minimize the distance between any two 
nodes. Although this method is much less restrictive than a shared bus, some overhead is 
still incurred as processing time is dedicated to the task of passing data. 
b. Circuit Switching 
In order to avoid the need for passing data along intermediate nodes, 
additional hardware can be used to assign specific temporary paths between processors 
wishing to communicate. This is known as circuit switching and exists quite commonly 
in the form of a telephone exchange. When one party dials another, a connection is made 
and dedicated for that specific communication for the duration of the call. When the call 
is complete, the connection is broken and may be used for a new connection. This clearly 
avoids the overhead of intermediate nodes passing data, however, new overhead is 
created in the task of managing the available connections. In circuit switching, the 
connection must be made and broken for each communication, and the event of "busy" 


connections must be handled. 


B. TRANSPUTER TECHNOLOGY 

Another technology has evolved which attempts to combine the advantages of the 
examples mentioned above while hoping to avoid the difficulties. A device called the 
Transputer combines a processor with its own local memory storage and four specialized 


data paths or links designed to communicate directly with other Transputers. Thus, as the 


number of processors and processing power in the network grows, the amount of memory 
and links available also expand. By providing its own direct communications path, the 
problems of bus contention are largely overcome. However, every Transputer in a 
network larger than five nodes cannot communicate directly with each other since each 
Transputer contains only four hardware links. 

Although the number of communication paths grows as Transputers are added to the 
network, establishing a dedicated path directly between any two processors will not 
always be possible. To allow communications between any two nodes, the message must 
either be passed via intermediate nodes (packet routing) or additional hardware must be 
employed to connect a dedicated path (circuit switching). Because of the synchronous 
nature of communication in Transputers, packet routing may introduce deadlock if it is 
not implemented carefully [Ref. 3:p. 110]. 

As a further complication, growth in the number of links between Transputers 
increases the probability of communications failure. When communicating via links a 
failure of the medium causes the link engines involved to wait forever which will likely 
result in failure of the processing in progress. Even without link failures or synchroniza- 
tion limitations, packet routing systems incur a potentially significant overhead in passing 


data between nodes. 


C. MOTIVATION 

Modern weapons systems depend heavily upon the availability of powerful proces- 
sors tO monitor equipment, evaluate sensor inputs, display command and control 
information and calculate trajectories and weapons intercepts. Weapons systems control 
computers can be described by following characteristics [Ref. 4:p. 11]: 


* Physically distributed: specialized computers are located throughout the platform, 
each dedicated to specific tasks but also in communication with the others, 


* Fault tolerant: loss of some computers or some communications paths should not 
bring the entire integrated system to a halt, 


¢ High performance: to handle demands of sophisticated sensors, and 
¢ Flexible and extensible: to respond quickly to a changing threat environment. 

The AEGIS Modelling Laboratory at the Naval Postgraduate School considers the 
Transputer’s architecture and capabilities as potentially useful to fulfill the greater 
demands of future weapons systems [Ref 4:p.11]. Although parallel processors in 
general, and Transputers in particular can satisfy the above requirements, communica- 
tions between processors may still present unacceptable restrictions either in ability to 


link any two Transputers in the network or in delays in obtaining the connection. 


D. OBJECTIVES 

According to Lauwereins [Ref. 5:p. 223], "...The two major problems encountered 
when interconnecting cooperating microcomputers are the detection of parallelism in the 
application program and the overload of communication lines." No attempt 1s made here 
to develop methods for detecting parallelism. Instead, this thesis explores dynamic 
reconfiguration and link fault tolerance in a network of Transputers as a method for 
conducting concurrent processing without prohibitive control overhead and thereby 
Overcoming the difficulties noted above. 

The message exchange is a combination of procedures and "off-the-shelf" hardware 
allowing direct communication between any two processors in the network. In the 
message exchange, specific connections are dynamically requested, created and terminat- 
ed as required by the application code with the use of program controlled switches. Thus, 
its development served as a test vehicle in developing routines for software controlled 
link switches and link fault tolerance. The message exchange concept is in contrast to 
packet routing architectures in which all data as well as control signals are passed via 


intermediate nodes to reach non-adjacent destination nodes. 


Communication fault detection and recovery procedures are implemented to increase 
the reliability of the links and to ensure that requested connections are eventually 
completed when link resources become available. With a functional message exchange 
system, a programmer can insert specific task instructions within this structure and have 
program controlled access to all processors in the network without additional code to 


manage the communications. 


E. THESIS ORGANIZATION 

Chapter II describes in detail the various tools used, including Transputer architec- 
ture and operation, the principles upon which it is based, and fundamentals of the 
programming language employed. 

Chapter III describes the specific equipment upon which the message exchange was 
implemented. 

Chapter IV explains the code and structures of the message exchange program. This 
includes explanations of the various modules of the program in both normal operation 
and in the event of communications failure. 

Chapter V discusses the testing and evaluation of the message exchange and the 
aspects of program structure and communications load which affect performance. 

Chapter VI presents the conclusions reached as a result of development, using and 
evaluating the message exchange. Recommendations for further research concerning 


Transputers, integrated weapons systems and this project is also included. 


Il. THE TRANSPUTER 


A. COMMUNICATING SEQUENTIAL PROCESSES 

Transputer is a combination of the words transistor and computer to emphasize its 
intended purpose: a single-chip processor to be used as a fundamental building block in 
large collections of parallel processors in much the same way that transistors are basic 
components of more complex and capable devices [Ref. 6:p. 25]. By using a collection 
of Transputers, large parallel systems can be constructed which operates concurrently and 
communicates through links. The Transputer was developed by INMOS Limited of 
Bristol, United Kingdom, and has since expanded into a family of very large scale 
integrated (VLSI) components with different capabilities. A typical member of the 
Transputer family is a single chip containing processor, memory, and communication 
links which provide point to point connection between Transputers. 

Fundamental to the design of the Transputer is the concept of a process and how it 
relates to concurrency. A process consists of a list of instructions intended to be executed 
in sequence, and can be thought of as the program in execution in a single processor or as 
the entity to which the processor is currently assigned [Ref. 7:p. 55]. This definition 
applies not only to parallel processors but to a single processor whose processing power 
is sequentially shared, or time sliced, among multiple processes. 

Hoare’s [Ref. 8] Communicating Sequential Processes (CSP) is one model for 
concurrent or parallel programming, and is central to the design of the Transputer. In 
CSP, a program is a collection of processes which can be combined to execute 
sequentially on a single processor or in parallel on multiple processors. The data space 


for any process executing in parallel is disjoint, thus alleviating the need for sharing 


memory between processors. Although shared memory 1s not available, processes must 
still communicate with each other. Therefore, CSP utilizes message passing between any 
pair of parallel processes via declared communications channels between the two 


processes. 


B. PROCESSOR ARCHITECTURE 
A block diagram of a T800 Transputer is shown in Figure 2.1 and the major 
components are discussed in the following sections. Internally, a Transputer consists of a 
memory, processor and communications system connected via a 32 bit bus. The bus also 
connects to the external memory interface enabling additional local memory to be used. 
The processor, memory and communications system each occupy about 25% of the 
total silicon area, the remainder being used for power distribution, clock generators and 
external connections [Ref. 9:p. 27]. 
1. Central Processing Unit (CPU) and Sequential Operation 
The processor contains 32 bit processing logic, 32 bit integer arithmetic unit, 
instruction and work pointers and an operand register. The on-chip four kilobyte high 
speed memory, which can store both data and code, is directly accessed by the processor. 
Where larger amounts of memory are required, the processor can access a maximum of 
four gigabytes of memory via the external memory interface [Ref 9:p. 47]. Figure 2.2 
shows a block diagram of the processor. 
a. Register Set 
The design of the Transputer processor exploits the availability of fast 
on-chip memory by employing only six registers used in the execution of a sequential 
process. The combination of very few registers and a simple instruction set enables the 
processor to have relatively simple and fast data paths and control logic. The six registers 
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Figure 2.1. Transputer Architecture Block Diagram 





¢ The workspace pointer (W) which points to an area of memory storage where 
local variables are kept. 


¢ The instruction pointer (I) which points to the next instruction to be executed. 
« The operand register (O) which is used in the formation of instruction operands. 
« The A, B and C registers which form an evaluation stack. 
A, B and C are sources and destinations for most arithmetic and logical 
operations. Loading a value into the stack pushes B into C and A into B before loading 


A. Storing a value from A pops B into A and C into B. 
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Figure 2.2. Transputer Processor Block Diagram 


Expressions are evaluated on the evaluation stack and instructions refer to 
the stack implicitly. For example, the add instruction pops the first two values (A and B) 
from the stack, performs the addition, then pushes the result back onto the stack. The use 
of a stack removes the need for additional instructions to explicitly manuever data during 
the performance of an operation. Statistics gathered from a large number of programs 
show that three registers provide an effective balance between code compactness and 
implementation complexity. [Ref 9:p. 47] 

b. Machine Instruction Format 

The Transputer instruction set has been designed for simple and efficient 
compilation of high-level languages. All instructions have the same format and are 
designed to give a compact representation of frequent program operations. Instructions 
are eight bits long and divided into two parts. The low-order four bits are the data and 
the high-order four bits are the opcode or function as shown in Figure 2.3. The data is 
loaded into the lower four bits of the 32 bit operand register which is operated upon by 


the opcode. This allows 32 bits of data to be used if required. 


Instructions operate on the entire Operand Register as the operand 
All intructions load their data into the lower 4 bits 
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Figure 2.3. Instruction Format 


Four bits can provide identification for 16 instructions which are known as 
direct functions. Thirteen direct functions actually manipulate the processor. These 
single byte instructions are the most frequently used such as Store, load, calls and jumps. 
The three remaining instructions: Pfix, Nfix, and Opr manipulate the operand register by 
constructing and executing larger instructions. [Ref 9:p. 29] 

Pfix loads its four data bits into the operand register then shifts the operand 
register left four bits. Nfix is similar except the contents of the operand register are 
complemented prior to shifting left. Consequently, operands can be extended to any 
length up to the length of the operand register by a sequence of prefix instructions. 
Operands in the range of -256 to +255 (eight bits and two operation types) can be 
represented using one prefix instruction. Finally, Opr causes its operand to be interpreted 
as an operation, known as an indirect function, to be executed on the values held in the 
evaluation stack. This allows up to 16 such instructions to be encoded in a single byte 
instruction. However, the prefix instructions can be used to extend the operand of an Opr 
instruction just like any other. The instruction representation therefore provides for an 


indefinite number of operations. [Ref 9:p. 30] 
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Encoding of the indirect functions is chosen so that the most frequently 
occurring operations are represented without the use of a prefix instruction. These 
include arithmetic, logical and comparison operations such as add, exclusive or and 
greater than. Less frequently occurring operations have encoding which require a single 
prefix operation. Measurements show that about 70% of executed instructions are 
encoded in a single byte; that is, without the use of prefix instructions. Many of these 
instructions, such as load constant and add require just one processor cycle [Ref 9:p. 49]. 

2. Link Engines and Communications 

Four identical INMOS bidirectional links provide communication between 
processors, and between processors and other compatible signal sources. Each link 
consists of an input and output channel, and can perform simultaneous, independent input 
and output communications. Instructions are included in the Transputer’s instruction set 
for performing input and output operations using the links. A block diagram of a 
communications link is shown in Figure 2.4. Each link engine also includes an 
independent direct memory access (DMA) controller and serial communication logic. 
Initiating a transfer down a link takes about a microsecond (20 processor cycles), but 
once the transfer is started it will proceed with minimal direction from the processor, 
consuming typically only four processor cycles (per active link engine) every four 
microseconds [Ref. 10:p. 15]. Although communications are synchronized between 
sender and receiver, they are not synchronous with clock input (ClockIn) to the 
Transputer and are insensitive to phase. Thus, links from independently clocked systems 
may communicate providing only that frequencies are within specifications 
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Figure 2.4. Hardware Communication Link Block Diagram 





To execute an external communication via a hardware link, the communication 
link address, size and location of a message are specified. This initializes the DMA 
controller with the size and location of the message to be communicated. The process 
executing the communication instruction is suspended and a pointer for later resuming 
the process is saved. If available, another ready process from an active process list may 
then be executed. When both the sending and receiving links have been initialized in this 
manner, the message communication proceeds. When the communication is complete, 
the process which was suspended for communication is allowed to resume. A more 
detailed description of parallel process management is provided in [Ref 9]. 

Messages are transmitted by the links one byte at a time in a bit-serial format. 
After a receiver has recognized the reception of a byte and is capable of receiving 
another, the receiver transmits an acknowledge message. The transmitter will await 


reception of the acknowledge message before transmitting the next message byte. Since 
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the link hardware performs no error checking on messages, the purpose of the 
acknowledge message is solely to control the flow of message bytes between the links. 
Figure 2.5 shows a formatted message byte and an acknowledge message. INMOS 
recommends that error checking should be provided in software if external link length 
exceeds 0.9 meters. Additional hardware is available which can translate the link 
protocol into forms suitable for long haul communications and formats compatible with 
different system. Information regarding INMOS link connections and conversion to and 
from other protocols or signal technologies, including fiber optics, can be found in 
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Figure 2.5. Serial Communication Link Protocol 


Internal communications, that 1s, communications between parallel processes 
executing on a single Transputer, can also be performed. In this case, memory transfers 
and software register equivalents are used instead of the DMA link engines since all 
activity takes place within the same processor. A memory address and the size and 
location of a message are specified, then the communications instruction is executed just 
as in the external communication case. When both sending and receiving processes are 
ready to communicate, the task is accomplished by performing a memory-to-memory 
transfer of the message data. From the high level language programmer’s view, internal 


and external link communications are handled identically. 


3. Memory 

Memory addressing starts at the most negative 32 bit address (hexadecimal 
80000000) with four kilobytes of fast, static memory on-chip for high rates of data 
throughput. Each memory access takes one processor cycle [Ref 9:p 70]. It is important 
to note that the on-chip memory, which is rated at 50 nanosecond cycle time, is not used 
as a memory cache for off-chip memory, but as the first portion of one linear address 
range. A total of four gigabytes of memory can be addressed by the Transputer and 
accessed at a sustained rate of 26.6 megabytes per second (at 20 MHz clock speed) 
[Ref 9:p. 43], some of which is dedicated for specific purposes in Transputer operation. 


A memory map 1s shown in Figure 2.6. 
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Figure 2.6. 1800 Transputer Memory Map 


Off-chip memory is accessed through an external memory interface controlling a 
multiplexed 32 bit address and data bus. Since this one bus must be shared between 
address and data information access to external memory is considerably slower than 


on-chip. A range of three to five processor cycles is typically required to access off-chip 
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memory. For this reason, the programmer pursuing performance optimization should be 
aware of code and data placement in memory and ensure that frequently used variables 
and code segments are placed in on-chip memory. If faced with a choice, on-chip 
memory is better suited for data, since four instructions, eight bits each, can be obtained 
in one 32 bit fetch, hence code accesses are less frequent [Ref 10:p. 2]. 

Additional hardware is provided on the external memory interface to provide 
refresh cycles for dynamic random access memory. Control lines and signals are also 
provided to facilitate peripheral device direct memory access to the external segment of 
memory. 

4. Timers 

The Transputer provides two 32 bit timer clocks which ‘tick’ periodically. 
These timers provide accurate process timing, allowing processes to deschedule them- 
selves in a specific time and allowing the programmer to execute instructions at either an 
absolute time or after a relative interval from a current time. One timer is accessible only 
to high prionty processes and is incremented every microsecond, cycling completely in 
approximately 4295 seconds. The other is accessible only to low priority processes and 
is incremented every 64 microseconds giving exactly 15625 ticks in one second. It has a 
full period of approximately 76 hours. [Ref 9:p. 52] 

Instructions are provided for initializing and reading the current timer values. 
Additionally, instructions are provided for suspending execution of a process until a 
specified timer value is reached. To implement this instruction, the Transputer maintains 
a linked list of suspended processes waiting on timer values. Separate lists are 
maintained for the high and low priority timers. 

A process can arrange to perform a timer input in which case it will become 


ready to execute after a specified time has been reached. The timer input instruction 
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requires a time to be specified. If this time is in the past then the instruction has no 
effect. If the time is in the future the process is deschedule and rescheduled when the 
time 1s reached. 

5. External Event Input 

EventReq and EventAck provide an asynchronous handshaking interface 
between an external event and an internal process and behaves similarly to an external 
interrupt input. To the Transputer, this external event input appears as a communications 
channel which is capable of transmitting a signal to a user’s program. 

A user’s program requesting input from the external event channel will be 
suspended if the external event input is not being asserted. Then, when the external event 
input is asserted the process will be added to the end of an active process list to wait its 
turn for execution. Either high or low priomty processes may request input from the 
external event channel, but only one process may use the event channel at any given time. 

6. Floating Point Unit (FPU) 

The 64 bit FPU of the T800 Transputer provides single and double length 
arithmetic floating point standard ANSI-IEEE 745-1985. It is able to perform floating 
point arithmetic concurrently with the CPU sustaining in excess of 2.25 Mflops on a 30 
MHz device. All data communication between memory and the FPU occurs under 
control of the CPU. [Ref 9:p. 62] 

The FPU consists of a microcoded computing engine with a three element 
floating point evaluation stack for manipulation of floating point numbers. Each stack 
register can hold either 32 bit or 64 bit data, indicated by an associated flag which 1s set 
when a floating point value is loaded. The FPU stack behaves similar to the CPU stack 


described in Chapter IT. 
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7. Benchmarks Performance Comparisons 
Shepherd [Ref. 13:pp. 10-13] provides the benchmark data shown in Table 2.1 
comparing members of the Transputer family with various other machines. Dhrystones 
and Whetsones are standard algorithms used in measurement of processor capability. 
Reference 13 includes the test code used, as well as complete reference listings of all 
third-party tests and vendor publications. 
TABLE 2.1 
TRANSPUTER PERFORMANCE BENCHMARK COMPARISONS 


Dhrystones | Single Precision | Double Precision 
per Second Whetstones Whetstones 
IBM 3090/200 7 n/a n/a 


T800-30 (projected) 6,000 3,800 
T800-20 4,000 2,900 
VAX 8600 

Intel 80386-16 
Motorola 68020-17 
Intel 80286/80287 
VAX 11-780 (+FPA) 
SUN 3 

T414-20 

Motorola MC 68000-8 
IBM PC-RT (+FPA) 
Intel 8086/8087 

IBM PC-RT 

















Computer Evaluated 
all figures in thousands 
(n/a: figures not available) 



















C. PROCESSOR OPERATION - PARALLEL MODE 


I. Process Representation 
In both sequential and parallel operation, the fundamental unit of execution is 
the process. A process may consist of many sub-processes executing concurrently by 
sharing the processor’s resources. A process may be assigned as either a high or low 
priority in execution. High priority processes execute without external interruption, 


while low prionty processes run until blocked by communications or timer inputs. 


Parallel operation is based on the following assumptions [Ref 4:p. 24]: 


* The quickest context switch is made by saving the least amount of data for any 
given process, 


¢ A process must perform I/O, or 


- A process not performing I/O is in a loop and must eventually execute a loop end 
instruction or jump instruction, and 


¢ A high priority process needs to execute as soon as it is ready, and executes until 
completion or blocked for communication. 


A concurrent process may be active at any time, in which case it is either 
executing or on a list waiting to be executed. Inactive processes are ready to input, ready 
to output, or waiting until a specified time. 

Concurrency administration in the Transputer is implemented in hardware, 
unlike most multi-tasking systems in which control takes place in software. The 
following hardware support is provided for implementation of parallel operations 
[Ref 9:p. 31]: 

¢ Two Timing Registers, 

¢ Four Process Queue Registers, and 

¢ Special registers for saving some process context switch data. 
2. Process Priority and Interrupts 

Each concurrent process is represented by a vector of words in memory called 
the process workspace as shown in Figure 2.7. A process is in one of three states: 
executing, ready, or blocked and the Workspace Pointer Register points to the executing 
process. This space is used to hold the local variables and temporary values manipulated 
by a process. The workspace is organized as a falling stack with end-of-stack addressing. 
All local variables are addressed as positive offsets from the Workspace Pointer. 


[Ref 9:pp. 28-31] 
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Workspace: 

used to hold local variables and 
temporary values manipulated 
by the process. 


Workspace Pointer 
_— 

3 Instruction Pointer 
(for descheduled processes) 
= Linkage Information 


(for scheduling communication 
and timer inputs) 





Figure 2.7. Process Workspace 


3. Process Scheduling 

The scheduler operates to avoid having inactive processes consume any 
processor time. Active processes waiting to be executed are held on a linked list of 
workspaces implemented using two registers: one pointing to the first process on the list 
and the other to the last. Figure 2.8 shows process S in execution, processes R, Q and P 
awaiting execution. 

A high priority process is executed (chosen in order of receipt) until it is unable 
to proceed because it is awaiting an input or output, or waiting for the timer. Whenever a 


process is unable to proceed, its instruction pointer is saved in its workspace and the next 
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process is taken from the list. Actual process switching times are very small as little 
process state information needs to be saved; even the evaluation stack is not saved in 


process rescheduling [Ref 9:p. 31]. 
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Figure 2.8. Linked Process List 








When a low priority task is executing and a high pnority task is ready, it 
preempts the low priority task. Generally, this takes place at the end of the current 
instruction. Some instructions, like block moves and I/O, are interruptible. In the event 
of such an interrupt the state of the low priority process is saved in special system 
memory locations at the low end of on-chip memory and the workspace pointer is placed 
at the head of the low priority queue. Note: high priority tasks are not pre-empted. 
[Ref 4:pp. 25-28] 

The process context switch time is low since only six registers need be saved 
and stored in fast, on-chip memory. There is full machine instruction level support for 
context switching which yields very low overheads. Occam context switching overhead, 
about one microsecond, is comparable to conventional control structures (e.g., loops, 


procedure calls). [Ref. 14:p. 139] 
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4. Time Slice Periods 

Low priority processes share the processor in time sliced intervals. A time slice 
period is defined as 5120 cycles of the external five megahertz clock, or about one 
millisecond. When a running low priority process has consumed its allotted time slice, 
the scheduler attempts to deschedule the executing process to make the processor 
available for the next processes on the queue. [Ref 9:pp. 50-51] 

Processes are descheduled at the end of their time slice, or shortly thereafter (to 
allow for completion of the currently executing instruction), and added to the end of the 
low priority queue. In general, the minimum period of time for time-slicing low priority 
processes 1s one millisecond with the expected maximum period being two milliseconds. 
Given n low priority processes and no high priority processes, the maximum time a 
process will wait in the process queue for CPU time is 2n-2 time slice periods. 
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D. PROGRAMMING LANGUAGE - OCCAM 

Transputers can be programmed in most high level languages, and are designed to 
ensure that compiled programs will be efficient. Where it is required to exploit 
concurrency and still to use standard languages, Occam can be used as a harness to link 
modules written in selected languages. Occam and Transputers were designed together 
based on Hoare’s CSP. Transputers include special machine instructions and hardware to 
provide maximum performance and optimum implementations of the Occam model of 
concurrency and communications. Therefore, to gain the most benefit from the Transput- 
er architecture, the whole system can be programmed in Occam. This provides all the 
advantages of a high level language, maximum program efficiency and the ability to use 


the special features of the Transputer. [Ref 9:p. 3] 
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Many programming languages depend on the existence of the uniformly accessible 
memory found in conventional single processor computers. As discussed in Chapter I, 
such an architecture would likely require the existence of a shared bus which itself 
becomes a bottleneck as the number of processors in a multiprocessor system grows. The 
aim of Occam is to remove this difficulty by expressing arbitrarily large systems in terms 
of localized processing and communication. INMOS describes Occam as follows: 

The main design objective of Occam was therefore to provide a language which 
could be directly implemented by a network of processing elements, and could 
directly express concurrent algorithms. In many respects, Occam is intended as an 
assembly language for such systems; there is a one-to-one relationship between 
Occam processes and processing elements, and between Occam channels and links 
between processing elements. [Ref 2:p. 5] 

Occam can further be considered an assembly language in that memory is viewed as 
a linear object and all resources are assigned at compile time thereby precluding 
recursion or dynamic resource allocation. The general simplicity of the language is 
recognized by being named after William of Occam, a 14th century philosopher who is 
responsible for the adage (known as Occam’s razor): "Entities are not to be multiplied 
beyond necessity" [Ref. 15:p. 1]. Hoare [Ref. 16:pp. 75-83] echoes this idea by stating, 
",.. here are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies and the other way is to make it so 
complicated that there are no obvious deficiencies. The first is far more difficult...” 

Another attractive feature of Occam is that its semantics can be formally stated. 
Welch [Ref 14:p. 146] describes Occam as a formal logic for the expression, transforma- 
tion and qualitative analysis of parallel, sequential and nondeterministic systems. By 


analysis of a language which adheres to formal rules it becomes possible to analyze a 


program in order to prove that it is, for example, deadlock free. Formal techniques can 


also be used to transform a program into different but equivalent forms for either 
efficiency or readability, or to adapt parallel code to run on a single processor and vice 
versa [Ref 15:p. 132]. 

1. Processes 

Occam enables an application to be described as a collection of processes which 
operate concurrently and communicate through channels. In such a description, each 
Occam process describes the behaviour of one component of the implementation, and 
each channel describes a connection between components. The design of Occam allows 
the components and their connections to be implemented in many different ways. This 
additionally allows the choice of implementation technique to suit available technology, 
to Optimize performance, or to minimize cost [Ref 2:p. 5]. 

Each process can be regarded as an entity with internal state, which can 
communicate with other processes using direct communication channels. Processes can 
be used to duplicate the behaviour of specific entities such as a logic gate or a 
microprocessor. Processes are finite: each starts, performs a set of instructions then 
terminates. Processes may be nested within each other much as subprocedures are 
contained within procedures in other languages. 

2. Constructs 
a. Sequential: SEQ 
A fundamental building block of sequential code is the SEQ statement. 
Occam code is written sensitive to horizontal indentation of the each line. Blocks are 
defined, therefore, by their depth of indentation. A block of sequential code is headed by 
the keyword SEQ and followed by the code indented two spaces as in the example 
below. The ":=" is the assignment symbol which is one of Occam’s three primitives. 


The other primitives, "!" and "?", are discussed below. 


SEQ 


Xx := atb 
ye:m@o* d 
z:=x/y 


b. Communication 

A connection formed between two concurrent processes is known as a 
channel and implemented either internally in the case of the two processes existing on the 
same processor, or via hardware links in the case of multiple processors. Communica- 
tions are synchronized and unbuffered. If a channel is used for input in one process and 
output in another, communication takes place when both processes are ready. Since a 
process may have concurrency, it may have many input and output channels performing 
communication at the same time. 

Channel input "?" and channel output "!" along with the assignment ":=" 
form Occam’s three primitives. An example in Figure 2.9 below shows use of 
communication constructs in a simple buffer. The process as pictured communicates via 


two channels declared “in" and "out". A series of variables assigned to "item" are 


sequentially taken in and sent out of the process. 


WHILE TRUE . a 
SEQ i item 
in ? item 


out ! item 





Figure 2.9. Single Element Buffer 





c. Parallel: PAR 
The parallel construct keyword is PAR and has placement rules similar to 
SEQ. Unlike SEQ, however, each line below PAR in the next indentation will be 
logically executed in parallel and considered concurrent processes. In the example here 


the three statements are executed simultaneously. [Ref. 17:pp. 15-17] 


tI 
Can 


PAR 
in ? itema 
out ! itemb 
x := itema + itemb 


The parallel construct is unique to Occam and provides a straightforward 
way of writing programs which directly reflects the concurrency inherent in real systems. 
A more involved example using a two stage buffer is shown in Figure 2.10 below. Note 


the indentation of the SEQ blocks indicating the two executing parallel processes. 


PAR 
WHILE TRUE 
SEQ 
in ? itema 


ch ! itema 





Figure 2.10. Two Element Buffer 


A priority level can be used with the PAR construct to form high and low 
priority processes. The PRI PAR construct designates the first process in the following 
indentation level as high priority, and the rest as low priority. If, as in the example 
below, there are five processes executed in parallel and it is desired that two be assigned 
high priority, a combination of PRI PAR and PAR can be used: 

PRI PAR 
PAR =-— higneprioricy 
processl 
process2 
process3 -- low priority 


process4 
process5 
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Since the PAR construct is more difficult to implement and more demand- 
ing of CPU resources it should not be used in situations where SEQ would suffice. 
Burns [Ref 15:p. 29] states that PAR should be used instead of SEQ when: 

* It more accurately reflects the properties of the program, 


* It allows the subprocesses to be arranged and thus enables program transforma- 
tions to be applied, 


¢ It allows channel operations to be executed in an order determined by the 
dynamics of the program’s execution rather than by a predefined and meaningless 
sequence. 
d, Alternation 

The alternative construct, ALT, waits until one of the listed conditions 
becomes true, then performs that guard and any subsequent code grouped with it. The 
ALT construct provides a forma! high level language method of handling external and 
internal events that are usually handled by assembly level programming in conventional 
microprocessors. A guard under an ALT is usually a channel input but can be other 
boolean conditions or combinations. In the first example below, two channels are 
awaiting input and each has a process associated with it. The process associated with the 
first channel that becomes ready will be executed. The next example shows a boolean 


condition and combination channel input and boolean as as ALT guards. 


[Ref 17:pp. 18-19] 


ALT ALT 
C2. xX (x_< YY + 5) .& SKEP 
processl process3 
c2 ? y c3 ? z & continue 
process2 process4 


Alternation is entirely nondeterministic in that the choice taken is not 
predictable since it depends upon actions performed by other independent concurrent 
processes. Furthermore, if more than one choice in an alternation becomes ready 


simultaneously, the guard selected is undefined in Occam. In practice, however, the last 


defined of the guards becoming ready simultaneously will be selected. This is strictly a 
matter of the compiler’s implementation of the language and not of the language 
definition. In order to force selection of a particular guard when more than one become 
ready simultaneously, the PRI ALT can be used to give preferential treatment to the first 
guard in the list. [Ref 17:p. 72} 
e. Loop and Selection 

Loops and conditional selections in Occam are very similar to other high 
level languages. Conditions can be any legal expression which evaluates to a boolean 
value. The constructs follow the same rules of blocking and indentation as mentioned 
above with the SEQ keyword used to head a block. The examples below show a finite 


and infinite WHILE loops. 


WHILE (x - 5) > 0 WHILE TRUE 
SEQ ALT 
x := x - 2 cl? x 
1 :=1i+i1 c2 ! x 


Selection is accomplished with IF and CASE constructs typical in many 
languages. The code associated with the first expression which evaluates to true will be 
executed in an IF with multiple choices. To ensure completion of the IF construct in 
Situations where it 1s possible none of the conditions are met the last condition should 
always be TRUE and its associated code may be a SKIP. For clarity, a boolean constant 
“otherwise” can be declared and set to TRUE to replace the keyword as the last choice in 


the IF construct: 


IF 
(x - 5) > 0 -- first condition to be tested 
x ~= x * 2 
(x = y) -- next condition to be tested 
y:=x - § 
otherwise -- otherwise assigned TRUE 
SKIP 
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f. Replication 
A replicator is used with SEQ, PAR, ALT or IF constructions to replicate 
the component process a number of times. This ability allows for creation of multiple 
code segments, each with potentially different parameters based on the incremented index 
of the process. For example, a replicator can be used with SEQ to act as a conventional 
loop or with a PAR to construct an array of concurrent processes Pl, P2, ... Pn 
[Ref 17:pp. 20-21]: 


SEQ i= 0 FOR n PAR 1 = 0 FOR n 
x := x * 2 Pi 


3. Configuration 

Assignment of processes to specific processors is called configuration. In a 
sense the configuration section of an Occam program can be considered as the "main" 
block in other languages in which the working code primarily calls previously defined 
procedures and passes variables. Link assignments and global variable passing is 
performed during configuration. The keyword PLACE ... AT is used to assign processor 
links to processes. 

Since each processor executes its code concurrently with other processors, a 
variation of the PAR construct, PLACED PAR is used. In the example below a 
network of processors will be assigned the process "process.a" using a replicated 
PLACED PAR. Note that each process.a is also passed as a parameter the value of its 
respective "index" which may be used in specializing the actions of each replicated 


process. 


PLACED PAR index = 0 FOR number.of.processors 
PROCESSOR number.of.processors 
PLACE input.channel AT link0O.in 
PLACE output.channel AT link2.out 


process.a (input.channel, output.channel, index) 
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4. Program Development 
Considering that parallel programming involves multiple processors, in most 
cases there will be many ways to perform the same task. Finding the optimum 
arrangement of processes and priorities will involve experimentation. Another design 
intent of Occam is that the logical behavior of a program is independent of how the 
processes are assigned to processors. According to INMOS: 

It is guaranteed that the logical behaviour of a program is not altered by the 
way in which the processes are mapped onto processors, or by the speed of 
processing and communication. Consequently a program ultimately intended for a 
network of Transputers may be compiled, executed and tested on a single computer 
used for program development. Even if the application uses only a single Transput- 
er, the program can be designed as a set of concurrent processes which could run on 
a number of Transputers. [Ref 9:p. 18] 

This guarantee 1s useful in using a single Transputer to create complex programs 


destined for multiple processors. Figure 2.11 shows the equivalence of single and 


multiprocessor code, and the relationships between internal and external channels. 


= i sy 
é Process 
|| Processor 


Figure 2.11. Single And Multiprocessor Equivalence 





5. Programming Practices 
Significant influence of program performance can be achieved by use of priority 


in parallel constructs. Correct use of prioritization is especially important for most 
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distributed processes communicating via links and dependent upon prompt data flow for 
timely program execution. If a message is transmitted to a Transputer and requires 
throughrouting, as in a hypercube topology, it is essential that the Transputer input the 
message then Output it with minimum delay so that another Transputer somewhere in the 
system would not be unnecessarily delayed waiting for the message. [Ref 10:p. 13]. 

Therefore, all processes which use links (external channels vice internal 
channels) should be run at high priority. Processes which perform calculations only or a 
minimum of communications should be run at low priority to preclude degrading the 
efficiency of those processes performing external communication and subsequently the 
efficiency of the network as a whole. 

6. Programming Environment 

The Occam compiler is packaged by INMOS within the Transputer Develop- 
ment System (TDS), which provides compilers, libraries, a debugger, a unique text editor 
and other facilities. 

Code is entered within a "fold" editor: a text editor in which any number of lines 
can be "folded" or replaced with a user defined header line. By using folds to condense 
blocks of code, the entire program may always be viewed on just one screen without 
having to page-up or page-down, or requiring a multiple window environment to view 
different blocks of code simultaneously. A fold header line is identified by three leading 
periods followed by the fold title, for example: "... fold title". Folds may be nested to 
any level, and if selected wisely, can show the overall structure of a program with the 
details hidden within the folds. To see the details the fold is entered and only the 
contents of that fold are seen. Optionally, the text surrounding the fold may remain 


visible, but will usually be off screen depending upon the size of the fold contents. 
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The fold editor and compiler work together as there are several specialized types 
of folds). A PROGRAM fold contains code intended to be booted and run on a network 
of Transputers external to the development board (described in Chapter IT.) located in a 
desktop personal computer (PC). Executable (EXE) folds contain code for the develop- 
ment board in the PC. Both PROGRAM and EXE folds may contain separately 
compiled, or SC folds to break up the code into stand alone units which may be compiled 
and modified separately without affecting others thus reducing recompile time for minor 
changes. Library (LIB) folds are also available either predefined or created by the user to 
contain global information which is referenced within appropriate PROGRAM, SC, or 
EXE folds. Finally, any fold may be temporarily removed from compiler action by 
nesting it withina COMMENT fold. [Ref. 18:pp. 13-22,40,84-86] 

Transputer Development System version D700D was used for this project. 
Version D included, among other utilities, a debugger for error tracing. The debugger 
was useful when used on code written for the BOO4 development board. However, as 
may be expected, tracing errors in an external network of Transputers is difficult. 


Complete details of the TDS can be found in [Ref 18]. 


Ill. MESSAGE EXCHANGE HARDWARE 


The following sections discuss in detail the equipment used in the implementation of 
the message exchange. A complete diagram showing major component relationships is 


provided at the end of this chapter. 


A. C004 LINK CROSSBAR 
1. General 

The IMS C004 is a programmable 32-way crossbar switch that supports the 
INMOS link protocol to provide synchronized communication between similarly 
equipped components. A crossbar can be thought of as a matrix of switches which 
permit, in the case of the C004, any one of the 32 inputs to be directly connected to any 
one of the 32 outputs. Figure 3.1 shows a block diagram of an IMS C004. 
[Ref 9:pp. 367-368] 
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Figure 3.1. IMS C004 Block Diagram 


This ability to manipulate 32 connections serves to greatly expand the flexibility 
of the Transputer which typically contains four link engines. (Some specialized Trans- 
puters have only two links, and new models are planned with eight). In the normal 
situation, therefore, a Transputer may be directly connected to a maximum of four other 
Transputers or link-equipped devices. If the applications requires that more than four 
Transputers be logically connected, intermediate Transputers must be programmed to 
pass data along to the desired destination, but only after incurring delays and additional 
overhead as compared to a direct route. Use of a program controlled crossbar precludes 
this problem by allowing one (or more) links from the Transputer to be directly 
connected to as many as 32 different links. Thirty-two Transputers can be completely 
configured using two IMS CO004s [Ref. 19:p. 13]. For applications requiring even greater 
flexibility, arbitrarily large crossbars can be constructed by cascading multiple CO04s as 
described in [Ref 19:p. 8]. 

2. Hardware Description 

The C004 is packaged in an 84 pin grid array chip and internally organized as a 
set of 32-to-1 multiplexers. Each multiplexer has associated with it a six bit latch, five 
bits of which select one of 32 inputs as the source of data for the corresponding output. 
The sixth bit is used to connect or disconnect the output. When this last bit is set high the 
link is considered to be active. These latches can be read and wnitten by messages sent 
on the configuration link via ConfigLinkIn and ConfigLinkOut. Figure 3.2 shows the 
C004 hardware implementation. [Ref 9:p. 377] 

A reset input is also provided to clear all latches so that no connections are 
active. CapPlus and CapMinus are connections for an external capacitor, and LinkSpeed 


sets the transfer rate through the crossbar at either ten or 20 Megabits per second. 
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ClockIn provides input from a five MHz clock used by the C004 for internal component 
timing. Recall, however, that input communication synchronization is not dependent 


upon ClockIn or its phase. [Ref 9:pp. 368-372] 
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Figure 3.2. IMS C004 Hardware Implementation 


oS 


Although C004 crossbars can be cascaded in multiple connections to any depth 
without loss of signal, each crossbar does introduce an average 1.75 bit signal delay 
which arises when the output of each multiplexer is synchronized with an internal high 
speed clock and regenerated at the output buffer [Ref 19:p.1]. This delay becomes 
significant when more than two C004s are connected in series due to the link protocol 
described in Chapter IJ. In the T800 Transputer, maximum transmission rates are 
accomplished by transmitting the acknowledge packet to the sender as soon as the first 
few bits of the 11 bit data packet is received. Therefore, the sender will be able to send 
the next data packet without delay since it would have already received the acknowledge 
for the current data packet. Communications through a series of COO4s will cause a 
signal delay of approximately four to five bits, which in turn causes a gap to occur 
between consecutive data packets since the sender must wait for the arrival of the 
acknowledge. A single C004 inserted between two linked Transputers which fully 
implement overlapped acknowledges causes no reduction in bandwidth [Ref 19:p. 5]. 

3. Software Commands 

Commands and responses are transmitted to the C004 via the ConfigLinkOut 
and ConfigLink/n lines from a controlling Transputer. All communications are in sets of 
one, two or three bytes. Byte values zero through 31 are used to reference a crossbar link 
number. Bytes values zero through six are used to specify one of seven commands listed 
in Table 3.1 [Ref 19:p. 3]. If a message of an unspecified configuration is sent to the 


C004 the effect is undefined. 
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TABLE 3.1 
C004 CROSSBAR CONTROL COMMANDS 


CONFIGURATION COMMAND FUNCTION 
COMMAND [Bytes] 

















QO] [input] [output] }Connects specified input to output (unidirectional). 





[1} [linkI] [link2] Connects link] to link2 by connecting the input of link] to the 
output of link2 and the input of link2 to the output of link]. 

[2] [output) |Enquires which input the output is connected to. The C004 
responds with the input link byte designation. The most 
significant bit of this byte indicates whether or not the link 1s 
actually connected (bit set high) or disconnected (bit set low). 


4] | 
| 
| 


















Essentially a pause command which should be sent immedi- 
ately after a connection is made to ensure the links are ready 
to accept data. Necessary only if the connection will be used 
immediately upon established. 





[ 
Resets all] links on the C004 to disconnected status. 
[5] [output] Specified output is disconnected and held low. 
[6] [linkI] [link2] Disconnects the output of link] and the output of link2. 


B. B012 TRANSPUTER MODULE MOTHERBOARD 

The IMS BO12 is a module motherboard of standard eurocard design (220 mm by 
233.5 mm) which contains a collection of fixed and removable components. Two C004 
crossbars (designated IC2 and IC3, discussed in the following section) and a T212 
Transputer (IC1) are installed on the motherboard, and 16-pin slots are provided for a 
maximum of 16 removable Transputer Modules or TRAMS. TRAMS are available in a 
variety of configurations and sizes, some requiring more than one slot thus reducing the 
number of TRAMS allowed on the board. According to Watson [Ref. 20:p. 2], the 
design goals of the module motherboards with crossbars are: 


* To be able to build systems with any number of Transputer modules in any 
combination or type or size; 


¢ To be able to build a variety of different kinds of networks (e.g., arrays, trees, 
Giloe se CIC. ); 


ay 


¢ Enable any number of motherboards to be chained together; 
¢ Make Transputer link connections configurable by software; 


¢ To be able to run test and applications programs on Transputers without first 
configuring links; 


¢ Provide a standard hardware interface to configuration and applications software; 
¢ Make the Transputer hardware independent of the host system 
Two 96-pin edge connectors, Pl and P2, provide connections between the BO12 
components and other Transputers, as well as power supply to the B012. The TRAM slot 


and link edge connector arrangements are shown in Figure 3.3. 
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Figure 3.3. IMS B012 Slot And Edge Connector Arrangement 


1. Motherboard Configuration 
Connecting pins for each slot provides power, reset and clock signals to the 
TRAM and connects the links of the TRAM mounted Transputer to the motherboard. In 


general, TRAM link1’s and link2’s are connected head to tail in a bidirectional pipe, and 


linkO’s and link3’s are hardwired to the C004’s. When not all slots are populated with 
TRAMs, or when TRAMs larger than one slot are installed jumpers must be placed in the 
unused connectors to maintain connectivity of the pipe. [Ref. 21:p. 2] 

Some flexibility is provided by jumper block K1 which can break or rearrange 
the pipe into other configurations. For example, a four-by-four node matrix can be 
created by breaking the 16 slot hard-wired pipe into four segments by opening the 
appropriate K1 jumpers, then completing the mesh using crossbar connections. Instead 
of leaving the K1 jumpers open as in the mesh, a four-by-four node torus can be created 
by looping each four-Transputer segment into a ring, and making additional crossbar 
connections to loop the perpendicular dimensions. Variations in pipe configuration and 
C004 control can also be made via jumpers on the P2 edge connector. Figure 3.4 shows 
the 16 slots in a pipe with the variable connections via K1 and P2 identified. A specific 


pin-out of the K1 jumper block can be found in [Ref 21:p. 36]. 
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Figure 3.4. B012 Configuration Variations Via P2 and Kl Jumpers 
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Link1 on slotO is wired to P2 and is called PipeHead, and link2 on slot 15 is also 
wired to P2 and called PipeTail. By properly installing the jumpers in unused slots 
PipeTail will then connect to whichever slot is filled last on the BO12. By connecting the 
pipe heads and tails from multiple BO12s together, a large pipeline of TRAMs can be 
created. 

In a standard configuration, slotO is the first TRAM in the pipe and its linkO and 
link3 are connected to the C004s. Multiple BO12s may be connected in another pipe 
involving the T212s. However, slot0 can be accessed directly via P2 and K1 instead of 
the CO004s for specialized applications in which the TRAM in slot0 is used to control the 
T212 or the remaining TRAMs on the BO12. Thus, multiple BO12s can be chained 
together connected via the Transputer in slotO instead of the T212s. Normally, each linkO 
and link3 of all slots are connected to the two CO04s per the arrangement shown in 
Figure 3.5. [Ref 21:pp. 5-6] 

As shown, the link output signals from all the linkO’s on all slots are connected 
to the 16 inputs of one COQ04. The link input signals from all the link3’s on all slots are 
connected to 16 outputs of the same C004. The remaining 16 inputs and 16 outputs of 
that C004 are connected to the edge connector Pl. The other C004 is connected 
similarly, except that 16 of its inputs are connected to the outputs of all link3’s on all 
Slots, and 16 of its outputs are connected to the inputs of all linkO’s on all slots. The 


remaining inputs and outputs are connected to P1. [Ref 21:pp. 5-8] 
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The BO12 link switching organization using CO04s does not allow complete 
freedom to connect any link to any other. [Ref 21:p. 10] The result of this connection 
scheme does allow any linkO on any module may be routed via the CO04s to any link3 on 
any module in just one programmed connection on each C004. A link between any linkO 
to another linkO, or between a link3 to another link3 (henceforth defined as a “like-link”) 
may also be established, but only with the use of two programmed connections on each 
C004 and two appropriately selected link cables on edge connector P1. 

Edge ea P1 has three columns of 32 pins each: the pins in one column 
are all ground, another column are all link inputs, and the third are all link outputs. These 


32 connections represent half of all available connections on the two crossbars, with the 
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remainder hardwired to the slots. Therefore, each row of three pins provides a 
bidirectional link, and the 32 rows can be connected as the user desires to fulfil the needs 
of the application at hand. The 32 rows are numbered from 0 (at the top) to 31. Figure 
3.6 shows the connections routed to P1 and P2. [Ref 21:pp. 9-10,26] 
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Figure 3.6. B012 Edge Connectors P1 And P2 


A module motherboard has Up, Down, and Subsystem ports on the P2 connector 
which provide hierarchical control. A board is able to control a subsystem of other 
boards by connecting its Subsystem port to the Up port of the next board. By connecting 
the Down port of the first subsystem board to the Up port of the next a daisy chain of 
boards is established. At any point down the chain, a new subsystem may branch by 
Starting with a Subsystem port. This hierarchy is shown in Figure 3.7. BO12 architecture 
also provides flexibility by allowing different sources of reset initiation for different 
components. For example, if there are n slots on a motherboard, modules in slots one 


through n may be controlled from either the Up port of the board or may be part of a 


subsystem controlled by the module in slotO. [Ref 20:p. 9] 
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Figure 3.7. Transputer Control Hierachy 





2. 7212 Transputer Crossbar Controller 
A 7212 Transputer is used to control the two C004 crossbars on the BOQ12 
motherboard. The T212 has four links of which linkO and link3 are connected to the 
C004s. Link] and link2 are routed to the P2 edge connector, labelled ConfigUp and 
ConfigDown for access to external systems or routing back to other available connections 


on the BO12 such as PipeHead and PipeTai!. Configuration data for the C004 is fed into 
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one of the T212’s links (ConfigUp) from an external Transputer or from one of the 
TRAMs on the BO12. Figure 3.8 shows the link connections from the 1T212 
[Ref 21:pp. 10-12] 
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Figure 3.8. 1212 C004 Controller Link Organization 





The T212 Transputer follows the description in Chapter II above on the T800 
with some key exceptions. The T212 is a 16 bit processor with only two kilobytes of 
on-chip memory. Although the T212 can address additional memory externally, there are 
no provisions on the BOQ12 for additional memory. (Another Transputer model, the T222, 
is pin compatible with the T212 and holds four kilobytes of on-chip memory). Due to the 
16 bit architecture a maximum of 62 kilobytes of external memory can be accessed 
[Ref 9:p. 318] via separate 16 bit data and address signal paths. 

As a controller for the CO04s, the T212 is intended to hold a small program 
which directs the connections made by the C004s. This program can run independently 
of external inputs, or can receive direction from other Transputers via ConfigUp and 


ConfigDown. By making appropnate jumpers on the P2 edge connector, the T212 can be 
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included in the pipe formed by the TRAMs on the BO12. A standard configuration for a 
multiple BO12 board system is to form a daisy chain of control from a host via ConfigUp, 
and connecting subsequent ConfigDown to ConfigUp connections. [Ref 21:p. 12] 
3. Transputer Modules 

INMOS Transputer modules (TRAMS) are designed to form the building blocks 
of parallel processing systems in which more than the on-chip memory is required. They 
consist of printed circuit boards in a range of sizes which typically hold a Transputer, 
some memory, and perhaps some application specific circuitry. A TRAM needs only a 
five volt power supply, ground and a five MHz clock to operate. These are supplied to 
the module through pins connecting the TRAM to the motherboard. Other pins carry 
signals for the Transputer’s links and reset, analyze and error signals. [Ref 21:pp. 12-14] 

IMS B401 is the designation of the TRAMs used in this project. Each B401 
holds a T800 Transputer and 32 kilobytes of static random access memory and connects 
to the motherboard using one slot via two rows of eight pins each. Sixteen B401 TRAMs 
may be placed on one BO12 motherboard for a total of 16 Transputers and 576 kilobytes 
of memory. Figure 3.9 shows the pin arrangement of a B401 TRAM. Full details of this 
particular TRAM can be found in INMOS product information [Ref. 22]. 
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Figure 3.9. B401 TRAM Pin Arrangement 
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C. B004 DEVELOPMENT BOARD 
1. General 
Transputer components form a unique hardware environment which is not 
immediately compatible with most existing personal computers (PC) or main frames 
upon which development work is accomplished. The IMS B004 development board was 
designed to meet these needs by interfacing a Transputer memory with an IBM type 
personal computer allowing the software developer to edit, compile and test software 


using the PC as a host. Figure 3.10 shows a block diagram of the BO04 development 


board which fits in a full length eight bit slot of an IBM companble PC. [Ref. 23] 
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Figure 3.10. IMS B004 Transputer Development Board Block Diagram 





The BOO4 contains a T414 Transputer, two megabytes of memory and circuitry 
to connect with the host computer. This connection is made via one of the Transputer’s 
four available links and typically through linkQ. This leaves the remaining three links to 


connect to additional Transputers in the host PC or in other locations. When the B004 is 
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used as a host or root Transputer for a larger system, compiled code is booted via the 
BQ04 to the other Transputers along link connections. The TDS may prompt the user for 
the BOO4 link number being used to boot other Transputers. Once the first link is 
established, the TDS relies on the the configuration information provided in the 
PROGRAM fold to continue routing compiled code to the assigned Transputers. The 
order of external Transputers booted follows the order in which they textually appear in 
the PROGRAM’s configuration fold. Each Transputer to be booted is first reset by the 
host, booted with its assigned compiled code, then used to boot the next Transputer in the 
system. This process repeats as necessary, following configuration fold link definitions, 
until all external Transputers are booted. 

Backplane connections are provided for link hook-ups and subsystem control 
(Up, Down, and Subsystem) as discussed for the BO12. Jumpers are also attached at the 
backplane to connect one of the links and the susbsystem connection to the host PC. In 
this case, the host PC acts as the master controller of all Transputers in the network. 
Additional Transputers daisy chained to the BO0O4 are controlled hierarchically via the 
Down connection. [Ref 23:p. 10] 

BO04 interface to the host PC includes access to the PC’s resources such as 
monitor and mass storage. Depending on the compiler used, coded library routines may 
be available to display information on the monitor or store computed results on the hard 
disk. Transputer Development System D700 version D was used for this project to edit 
and compile the Occam program code. Extensive use of library calls to predefined 


display subroutines was made in order to facilitate monitoring and debugging of code. 
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2. T414 Transputer 

The B004 development board used contained a single T414 Transputer. With 
few exceptions, most of the information contained in Chapter II above applies to the 
T414 model. Unlike the T800, the T414 does not include an on-chip floating point unit 
and only holds two kilobytes of on-chip memory. [Ref 9:p. 179] 

T414 link communication protocols are the same as T800, however, the BO04 
T414 does not send the ACK packet immediately upon receipt of the first few bits of 
incoming data. Instead, the BOO4 T414 waits until the entire data packet is received 
before the ACK is sent. Although the T414 does support the high speed 20 megabits per 
second data transmission rate, other components on the BOQ04, particularly the PC 
interface [Ref 23:p. 14], restrict the T414 to ten megabits per second link speed. Since 
the [414 is used to intercept and test or record communications from the T212 occurring 
along the link controlling pipe of the message exchange, the entire system data flow rate 


is maintained at ten megabits per second. 


D. MESSAGE EXCHANGE HARDWARE CONFIGURATION 

A complete view of the message exchange hardware is shown in Figure 3.11. This 
diagram shows the relationships between the key components, including the C004 
crossbars, crossbar controller, TRAMs, and the B0O4 used in monitoring the system. 
Four TRAMs in slots zero through three are shown corresponding to the hardware used 
for this project. The numbers on the left and right sides of the figure show the 
connections between the edge connector Pl and the actual link designations on the 
CO04s. (The numbers under "P1 #" are pin row numbers on the edge connector). An 
arrow accompanies each pair of numbers indicating its communication direction: pointing 


towards the COQ04 for LinkIn and away from the C004 for LinkOut. 
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Figure 3.11. Message Exchange Hardware Configuration 
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IV. MESSAGE EXCHANGE FUNCTIONAL DESCRIPTION 


A. OVERVIEW 

Multiple processors connected in some topology can be described as belonging to 
one of three configuration categories: static, semi-static, and dynamic [Ref. 24:p. 124]. 
In the static topology, the interprocessor connections are fixed for the duration of the 
application. Any significant change requires system down time and hardware modifica- 
tion. Semi-static topologies allow for system reconfiguration at synchronized points as 
the application progresses. For example, one topology may be best for loading data, then 
once all data is loaded, all processors switch to a second topology better suited for 
processing the data. A third topology may later be used to output or display the results. 
The Esprit Project P1085 [Ref 24] discusses a large scale, semi-statically reconfigurable 
Transputer network which uses crossbars (72 x 72), a specialized control bus, and a three 
layer operating system. 

Most flexible of the three is dynamic configuration in which any processor can be 
dynamically connected to any other processor upon request while the application 1s 
running. Harp [Ref 24:p. 124] states that dynamic switching allows dynamic load 
balancing, fault tolerance and offers potential benefits for efficient implementation of 
high level languages. Although the greatest flexibility can be achieved with complete 
interconnectivity, dynamic configuration also incurs the greatest overhead in system 
maintenance. 

The message exchange program as developed here is intended to provide maximum 
flexibility in data transfer within a dynamically reconfigurable Transputer network. As 


explained earlier, each Transputer has four links with which to communicate to similarly 
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equipped components. If a given Transputer requires communication to more than four 
components, data must be routed through the intermediaries until it eventually arrives at 
the intended destination. 

The message exchange developed here uses the C004 crossbars on a BO12 
motherboard to establish direct connections between requesting Transputers. With this 
hardware, a process using one link of a TRAM can be directly connected to any of the 
other 31 TRAM links on a fully populated BO12 (that is, with 16 TRAMs). Additional 
code was also added to detect and recover from failed external links between crossbars 
used in making these connections. 

Hill [Ref 19] served as the basis for this program, however, significant modifications 
were made to complete the partial code provided and adapt it the hardware design of the 
BO12. The example cited was designed around a proposed use of a single C004 and 
employed all Transputer components as traffic routers for external processors. The 
program here uses both C004s of the BO12 and allows application code to be embedded 
in each TRAM for production work, with the remaining code serving as a communica- 
tions kernel which obtains the requested connections status. 

A functional description of the message exchange in both normal and link failure 
operations is discussed below, followed by a detailed explanation of the code in the 
Controller and TRAM modules. A complete listing of all message exchange code is 
provided in Appendix A. Code used in program development and testing is provided in 
Appendix B. Appendix C contains code for a visual display of message exchange 


activity which was used extensively in system debugging. 
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B. SYSTEM OPERATIONS 
1. Link Control Command Description 

Communications on the link control pipe consist of three-byte packets: one byte 
each for link command, source, and destination [Ref 19:pp. 16-17]. There are six 
commands issued by either the controller or any of the managers to operate the crossbars 
and thus dynamically control the network topology and recover from failed links. All 
commands are predefined in a library of constant definitions made available to the 
appropriate procedures. 

¢ REQ (link request) issued by a Manager (process on a TRAM monitoring link 
control commands) requesting the creation of a new link for one of its two Agents 
(processes on a TRAM performing data output) as a source. 

¢ ACK (request acknowledge) issued by the Controller (process on T212 link 
crossbar controller) when a requested link is successfully established, thus 
informing the Manager the new link is available. 

¢ REL (link release) issued by a Manager when an existing link is no longer 
needed. After communications are completed and the specified path no longer in 
use, the link resources should be freed for other users. 

¢ BRK (release acknowledged) issued by the Controller when the link has been 
released. This allows the Manager to repeat the cycle and request a new link to 
the next desired destination as necessary. 

- ABT (communications abort) issued by the Manager when an attempted 
outbound communication has exceeded a watchdog timer, thus signalling a 
communication failure. 

¢ RET (link reinitialization) issued by the Controller to synchronize reinitialization 
of both directions of both ends of the affected link. 

2. Link Failure And Recovery Procedures 
Under routine circumstances, that is, using only the Occam "!" and "?" 
primitives for external link communications, a hardware failure of the external link used 


may Cause the Transputers involved not only to lose data, but also to hang entirely 


Causing a need for a hardware reset. Transputer deadlock occurs as soon as a data packet 
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is sent along a link and its corresponding acknowledge packet is never received. (Or 
conversely, depending upon when the failure took place, an acknowledge packet is sent 
and the next data packet never arrives). Although a crossbar can be employed to switch 
in a "good" connection to replace the failed wire, the Transputers in use are still stuck as 
before while its link engine is waiting for a transmitted but lost packet which will not be 
regenerated by either Transputer. 

Recovery of a failed link and the Transputers involved, employs Transputer 
Development System procedures in the reinit library. These library procedures imple- 
ment input and output processes in lieu of the standard "!" and "?" primitives, and can be 
made to terminate the process even in the presence of a communication failure. The five 


library procedures and their associated parameters are as follows: [Ref 9:p. 271] 


e PROC InputOrFail.t (CHAN OF ANY c, []BYTE message, 
TIMER time, VAL INT t, 
BOOL aborted) 

¢ PROC OutputOrFail.t (CHAN OF ANY c, []BYTE message, 
TIMER time, VAL INT t, 
BOOL aborted) 


¢ PROC InputOrFail.c (CHAN OF ANY c, []BYTE message, 
CHAN OF INT kill, BOOL aborted) 


¢ PROC OutputOrFail.c (CHAN OF ANY c, []BYTE message, 
CHAN OF INT t, BOOL aborted) 


e PROC Reinitialise (CHAN OF ANY c) 


Input/OutputOrFail.t procedures take the following parameters: the data 
channel c which is to be guarded for faults, the actual data variable message, a timer 
channel time and a delay value t in clock ticks. The procedures return the boolean value 
aborted equal to true if the communication failed to complete in the allowed time 


interval t. If the communications are successful, the data is passed and aborted is set to 
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false. In either case, although the communications may fail, the library procedure always 
successfully terminates, thus protecting the system from failure. By using a timer to 
determine successful communication completion, these procedures are used to detect a 
failure and thus initiate recovery actions. Communication failure detection functions are 
assigned to the Agent process which is responsible for conducting data output on each 
TRAM in the message exchange. Figure 4.1 shows a state diagram tracing through the 


sequence of control commands involved in both normal and fault conditions. 


Request Not Able 
New Link To Make 
a aes New Link 

epeats - Now, Try 
(If Desired) ,” Again 


Link 
Failed 


Link Broken Reinitialize 





Figure 4.1. Link Control Command State Diagram 





In situations where a watchdog timer is not sufficient to detect communications 
failure, but where the failure can be detected by other means, the Input/OutputOrFail.c 
procedures can be used. Instead of reporting a failure based on a timer, this pair of 
procedures takes an additional external signal, an integer kill, to force the current 


communications to terminate. Since the data output routines in the Agent processes 
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detect and report a link failure, the communications input of the User processes use these 
external "kill" procedures to terminate a failed communication based on link control 
signals from the appropriate Agent via the link control pipe. By relying upon only the 
communication source (output) end of the link to detect link failures, timing difficulties 
and redundant fault signals inherent in the message exchange system are avoided. 

Finally, the Reinitialise procedure, which takes as its only parameter the 
communication channel c involved, actually resets the failed link engine allowing them to 
be reused. Reinitialise should be called only after both directions of both link engines 
are terminated (by the above procedures) and no further communication is attempted by 
them. Before a reset link engine is tasked with conducting communications, the crossbar 
controlling Transputer should have assigned a working connection to correct the fault. 
Repeated failures, however, are tolerable and the sequence of events in link recovery 
repeats until the desired communications are completed successfully using a working 
connection. 

3. Link Control! Command Action Summary 

Table 4.1 describes the life cycle of the various controlling commands as they 
are passed among the key modules in the pipe. Origination of each command is straight 
forward and not flexible, given the requirements of the system. However, termination 
(removal from pipe) of commands was altered several times during software develop- 
ment. In all cases possible, as soon as the command has travelled along the pipe to 
complete all its functions, the last station taking action on the command removes it from 
the pipe. When several components take action on a single command (link reinitializa- 
tion, for example), the command parameters may be modified allowing the terminal 
component to remove the command without fear of preventing the flow of needed control 


information. 
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TABLE 4.1 
LINK CONTROL COMMANDS AND PROGRAM MODULE ACTIONS 


CMD MANAGER 
Link. 


CONTROLLER 





With Source Involved - {| With] Involved 
REQ |lIf link made: 


Link.REQ Originates Link.REQ passed on. 
prompted by Agent, which 

is itself prompted by first 

byte of data message from 

User. 


Link.ACK passed on, 
source byte set to nil, noufy 
Agent to transmit data. 
Link.ACK Consumed if 
destination byte already nil. 


Link.REQ Consumed, 


Link.ACK Originates. 
If link not made: 
Link.REQ Recycled. 


Link.REI Originates. 
Link.REI Consumed. 





If link broken: 
Link.REL Consumed, 
Link.BRK Originates. 
If not broken: 
Link.REL Recycled. 


Link.BRK Originates. 
Link.BRK Consumed. 























Link.ABT passed on. 
Link.REI Originates. 
If new link made: 
Link.ACK Originates. 
If new link not made: 
Link.REQ Originates. 






Link.REI Originates. 
Link.REI Consumed. 









Link.ABT Consumed when 


circuit, ensuring destination 


Link.REI Consumed if 













Link.ACK passed on, 
destination byte set to nil, 
notify User to receive 
data. 

Link.ACK Consumed if 
source byte already nil. 


Link.REL Onginates Link.REL passed on. 
based on request from 

Agent upon successful 

completion of data trans- 


mission. 


Link.BRK Consumed, noti- 
fy Agent link is broken. 
User passes next data block 
to Agent. 


Link.ABT Originates 
based on notification from 
Agent of failed communi- 
cation. 


Link.BRK passed on. 








Link.ABT passed on, 
notify User to abort input 
of data. 

Note: destination User 
notices link failure only 
when informed via the 
command pipe. Failure 
detected by source 
Agent. 


Link.REI passed on, des- 
tination byte set to nil, 
notify User to reinitialize 









command makes complete 


informed of failure. 








Link.REI passed on, source 
byte set to nil, notify Agent 
to reinitialize link. 


link. Link.REI Con- 
sumed if source byte al- 
ready nil. 


destination byte already nil. 
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C. CONTROLLER MODULE 

The Controller code executes in a single process which resides entirely on the T212 
C004 controller installed on the BO12 motherboard. In the configuration established for 
this project, the T212 1s connected in a unidirectional pipe formed by the TRAMs on the 
motherboard. Link request and status information 1s circulated in the pipe until received 
by the Controller, at which time appropriate action is taken to either connect or 
disconnect a requested data path, or to recover from a reported failed path. The 
Controller directs the crossbar resources of the BO12 ensumnng that all requests are 
fulfilled, if physically possible, and avoiding potential system deadlock caused by partial 
allocation of resources. 

The Controller code consists of a main section which monitors the link control pipe 
and takes action by calling one or more of its four subprocedures, while also managing 
connection resources and status. Subprocedure’s functions will be discussed individually 
followed by an explanation of the main code for the Controller. 

1. Subprocedure: reset.or.nil 

When the enquire command and the output link designation of interest 1s sent to 
a C004, the response is the byte designation of the input link currently connected (see 
Table 3.1). The left most bit of the response byte (bit seven) indicates that link is active 
when set high, or inactive (disconnected) when set low. To define one of the 32 possible 
connections to any given output link, five switches must be set. Their status 1s indicated 
by the five lower bits of returned byte (bits four through zero). When a programmed 
connection is broken, only bit seven is changed (set low); the selection bits are altered 
only when a new link is established. Bits six and five of the enquire response byte are 


not used. 


a7 


Since past connections to a given link are of no interest to this program, the 
reset.or.nil procedure will return byte.nil if bit seven of the enquire response byte is 
low, thus indicating that the connection is inactive and free for assignment. If bit seven is 
high (indicating an active connection), reset.or.nil returns the current connected input 
link designation by resetting bit seven of the enquire response byte and leaving bits four 
through zero intact. Setting bit seven low is accomplished using the Occam "><" bitwise 
exclusive-or operator on the hexadecimal value 80 which isolates the left most bit of the 
C004 enquire response. This subprocedure is repeatedly called by other subprocedures as 
well as the main code. 

2. Subprocedure: c4.cmd 

A small code sequence used in communicating with the crossbars is used 
repeatedly throughout the Controller and is coded as a subprocedure for clarity and to 
improve memory usage efficiency (recall that only two kilobytes of memory are available 
on the T212). C4.cmd sends a command followed by zero, one or two parameters (as 
appropniate for the command: see Table 3.1) to a selected crossbar. The choice of 
crossbar command to implement is determined by the value of the parameters received. 
Upon completion, the returned byte is placed in parameter b3. The Occam keyword 
VAL coupled with other type identifiers, defines the parameters that follow to be 
constants for the duration of the subprocedure. 


PROC c4.cmd (CHAN OF ANY to.x, from.x, 
VAL BYTE cmd, bl, b2, BYTE b3) 


If the command involves a change of link status, c4.cmd code proceeds to 
immediately query the crossbar and verify the requested status change, for example: that 


the requested connection is created as desired. The result from the enquiry is then run 
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through the reset.or.nil subprocedure which transforms the crossbar response into a form 
indicative of the task accomplishment. For example, if a link was to be broken the value 
returned by c4.cmd (via use of reset.or.nil) would be byte.nil indicating a free link. 

3. Subprocedure: get.current.tie 

No program defined tables or records are kept by the Controller with regard to 
link Connection status. When a connection status must be determined, for example, to 
verify a link is free prior to making a connection, the CO004s are consulted directly. As 
discussed above, the enquire command is used to establish current connections. By 
sending the command with the byte designation of the output link of interest, the C004 
will respond with the byte designation of the currently connected input link. Reset.or.nil 
is then called to strip the high bit from the response if present, or change to byte.nil if 
not. 

Since the five selection bits (four through zero) of the enquire response byte 
change only when a new link connection is ordered or when the entire C004 is reset, 
Current status is always available and accurate. By relying strictly on the hardware 
switch positions internal to the C004s, potential errors in status table maintenance are 
completely avoided. Processor effort needed for C004 status enquiry is comparable to 
status table look-up and maintenance since all Controller code is sequential, therefore no 
competition exists for use of the links between the T212 and the C004’s. 

All subprocedures dealing with the C004s are passed four channels: to.c, 
from.c0, to.cl, and from.cl, which are the communication paths between the T212 and 
the C004s. The get.current.tie subprocedure is also passed the source or destination link 
of interest, and it returns either the designation of the current connection, or byte.nil if 


the link of interest is inactive. 
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PROC get.current.tie (CHAN OF ANY to.c0O, from.c0, 
£0.¢l,. froanecl, 
VAL BYTE in.link 
BYTE link.tied.to) 

Initially, get.current.tie must determine which C004 to enquire since linkQ’s 
and link3’s are connected differently (see Figure 3.3). This is complicated by the 
numbering scheme of the C004 links and the slot numbers that are hardwired to them. 
Therefore, a translation array is used to convert the C004 link designation to a slot 
number. In this program, linkO’s are numbered O through 15, and link3’s are numbered 
20 through 35. 

It should be recognized that a consistency between the C004 wiring schemes 1s 
relied upon to perform these operations. Regarding BO12 organization, Figure 3.3 
showed that for a given TRAM linkO or link3, the input is routed to one C004 and the 
Output to the other. Although different CO04s are involved, the C004 link designation 
used is the same. This is valuable since the enquire command responds only with the 
input link connected to the output link in question. There is no enquire to determine what 
Output is connected to a given input. Therefore, the connected output link 1s assumed to 
be the same link designation (although different CO04s) as the input link. This 
assumption has proved reliable since all connections are accomplished for both input and 
Output directions in tandem. 

4. Subprocedure: make.conn 

When the main code directs the establishment of a connection, the make.conn 
subprocedure is called. All actions necessary to complete the requested connection are 
contained in this subprocedure. Each routine includes a returned boolean value conn.ok 
which provides connection verification results. Make.conn is called with the four C004 


channels, source and destination bytes, and retums only the boolean conn.ok: 
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PROC make.conn (CHAN OF ANY to.cO, from.c0O, 
to.cl, f£rom.cl, 
VAL BYTE in.source, in.dest, 
BOOL conn.ok) 


Three distinct cases must be handled by this procedure: connect any link0 to any 
link3, connect any linkO to linkO, and connect any link3 to link3. The first, linkO to link3, 
is Straight forward since only one connection must be made on each C004 and the 
procedure is symmetmic for each link. Figure 4.2 shows how the crossbars are used to 
connect any linkO to any link3 on the BO12. Note that the linkO and link3 involved can 
even be of the same Transputer. After enquiring the C004s with the source and 
destination links of interest, make.conn orders the connection if both links involved are 
free. Otherwise, the procedure returns false for conn.ok. The remaining two cases, 
however, are much more complex in that two connections on each C004 must be used as 
well as an external edge connector jumper. Since like-link cases are similar, an internal 


subprocedure make.0033 is used. 


~“’——-_ Hardwired Connections Between TRAMs and C004s 
Software Controlled Connection in C004 Crossbar 





Figure 4.2. Crossbar Connections To Connect Any Link0 To Any Link3 
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Although the C004s can provide immediate status of all internal connections, 
there is no direct way to establish placement of the Pl edge connector jumpers on the 
BOQ12. Therefore, the user supplies a table eine the combinations of edge connectors to 
be used to satisfy either linkO to linkO or link3 to link3 requests. Sixteen jumpers can be 
arranged on the Pl edge connector pins, but not any jumper arrangement will satisfy 
either type of connection. Due to the design of the BO12, only specific combinations may 
be used to complete a like-link connection. Table 4.2 shows one selection of possible 
jumper arrangements. 

For this project, eight jumpers were selected for linkO to linkO connections and 
eight for link3 to link3. The user provides values in two byte arrays edge.a and edge.b in 
which the values for a specified index form a pair of edge connectors defining the 
location of a jumper. For example, edge.a[3] and edge.b[3] define connections 25 and 
26, respectively. This tells make.0033 that these C004 links can be used to jumper 
across from one C004 to the other to establish a connection between two linkQ’s. 


TABLE 4.2 


JUMPER PLACEMENT FOR C004 TO C004 CONNECTIONS 


For LinkO To Link0: | For Link3 to Link3: 
Connect P1 Row: To P!1 Row: Connect P1 Row: To P1 Row: 





The user also provides two integer values: edge0.ct and edge3.ct which are the 


number of possible jumpers available for each type of connection. The sum of edgeO.ct 
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and edge3.ct is the total number of jumpers installed. The first edge0.ct listings in the 
two byte arrays are for linkO to linkO connections, and the subsequent edge3.ct pairs are 
for link3 to link3 connections. 

A boolean table, edge.ok, maintained globally in the Controller module, tracks 
reported status of each edge connector. When a TRAM reports an edge connector has 
failed, the corresponding index in edge.ok is set to false. Only edge connectors with a 
corresponding edge.ok value of true are used to complete like-links. 

With the jumper information provided, the make.0033 subprocedure can 
proceed to establish a connection between two like-links. Figure 4.3 shows the 
necessary crossbar and jumper connections to accomplish this. As each crossbar 
connection is made the procedure immediately enquires the status of the assumed newly 
formed links and checks the returned answer against what is expected. Any deviation in 
comparing expected from actual status is treated as an incomplete connection and the 
make.conn procedure returns FALSE for the value conn.ok. 

5. Subprocedure: break.conn 

Procedure break.conn works similarly to make.conn in that the same three 
cases of link combinations must be handled, and the two cases involving like-links are 
handled with an internal subprocedure. Significant difference is that the CO04 command 
to disconnect links, c4.disconn.output, is sent instead of the command to make 
connections. Enquiries of link status are still conducted and the returned bytes are sent to 
the reset.or.nil procedure. Successful termination of a link is evidenced by all links 
involved showing the byte.nil status which shows that the links are now free for their 


next assignment. 
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~«t—— Hardwired Connections Between TRAMs and C004s 
Software Controlled Connection in C004 Crossbar 
seeeree* Bidirectional Link Cable on Edge Connector (AB to AB) 





Figure 4.3. Crossbar And Jumper Connections To Connect Two Like-Links 


It should be noted again that there are no link status tables to be maintained or 
updated. In all cases, link status is obtained directly from the CO004s involved to ensure 
accurate assignment and freeing of crossbar connections. 

6. Main Controller Code 

After variable initialization, the Controller module enters an infinite loop which 

constantly receives the next link control bytes and takes the appropriate action. Program 


structure 1s shown below followed by details of key folds. 


SEQ 
..initialize C004s, clock, 
and edge.ok status array 
WHILE TRUE 
ALT 
from.pipe ? token; source; dest 


token = link.req 


...action for connection request 
token = link.rel 
...action for connection release 
token = link.abt 
...action for failed link 
token = link.ack 
...action for recycled link acknowledge 
token = link.brk 
...action for recycled link break 
token = link.rei 
...action for recycled link reinitialize 
otherwise 
...action for unrecognized command 
(clock interval reached and 
failed request count limit exceeded) 
...reset a edge.ok status to TRUE 


a. Action For Link Request 

Upon receiving a link request, the status of the requested links are 
determined using get.current.tie. If the returned status for both source and destination 
are byte.nil (indicating free links), the requested connection is established using 
make.conn, and a link acknowledge (link.ack) packet is sent to the pipe to inform the 
TRAMs involved that a connection is made and data can be transmitted. If a requested 
link is currently busy, the link request is recycled through the pipe in hopes that the 
resources will be freed for reassignment by the time the request returns. Using the link 
control pipe as a waiting queue for failed requests ensures that the request will not be lost 
while it is waiting for resources, and also minimizes storage and processing requirements 


of the Controller code on the T212. 
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If the link request could not be fulfilled due to lack of available working 
"good" edge connectors, a counter is incremented tracking the number of such failed 
requests. When the req.cnt reaches a preset value, the edge connector management 
algorithm begins searching for repaired resources. This is explained in more detail 
below. 

b. Action For Link Release 

A link release command 1s a TRAM request that an existing link be freed 
for new use as needed. A single call to the break.conn terminates the connection and 
frees the resources. Although there is no resource conflict preventing a link from being 
disconnected, if the crossbar does not respond with the expected byte.nil status, link.rel 
will be recycled through the pipe and break.conn will be called again. Upon successful 
termination of a connection, a link break (link.brk) packet is sent, informing all 
concerned that the resources are free. 

Link request and release commands are the first two choices in the WHILE 
TRUE loop of the controller due to their frequency. In normal conditions, only these two 
commands will ever reach the Controller module for action. 

c¢. Action For Link Abort 

When a link abort (link.abt) is received, the command is immediately 
passed on to the pipe since additional action must be taken by other TRAMS. (The abort 
command is eventually removed by the originating TRAM). Next, the Controller 
determines the exact connection and its edgelist table index involved via the get.cur- 
rent.tie procedure. To prevent a known bad edge connector from being immediately 
reused by make.conn, the edge.ok value of the corresponding index is set to false. 

With the failed edge connector marked as bad, the Controller continues by 


sending a link reinitialize (link.rei) to the pipe so that both directions of both links 
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involved in the aborted communication may be reset. Note, the reinitialize command is 
sent after the link abort command to ensure that all communication attempts cease prior 
to completing the link engine reinitialization process. This is required by the TDS link 
engine recovery procedures. At this point, the existing failed connection is formally 
broken with break.conn and remade with make.conn using a different path. 

From here, the procedure is similar to that of the link request action above. 
If the connection cannot be reestablished, a newly generated link requested is placed in 
the pipe. If the failure to make a new connection is due to lack of edge connector 
resources, the req.cnt counter is incremented. If a new connection is made, a link 
acknowledge is placed in the pipe to inform the TRAMs involved to attempt communica- 
tions again. 

d. Action For Link Acknowledge, Break And Reinitialize. 

Under normal circumstances, these commands are removed by the last 
TRAM which takes action based on their receipt. If a TRAM fails to remove such a 
command, they will be removed here to prevent the pipe from being flooded with 
meaningless circulating commands. 

An additional section is added to pass noncommands along the pipe. This is 
used exclusively for testing purposes when specialized test commands were placed in the 
pipe to monitor specific actions. Such testing or status information, like TRAM code 
completion, 1s removed by the BO04 monitoring the system. 

e. Edge Connector Status 

Also within the WHILE TRUE loop is a block of code which manages the 
status of the edge connector links. Initially, Controller is told by the programmer which 
connections are hard wired and that their status is "good", that 1s, the edge connectors as 


listed in the data library edgelist are immediately available for use to establish 
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connections between like-links of TRAMS. If a TRAM detects and reports a failure as 
the message exchange proceeds to make and break links, the Controller marks the edge 
connector involved as "bad" and avoids assigning it in the future. This points out a 
Sharing of responsibilities between the Controller and TRAM processors. An Agent ona 
TRAM has no knowledge of the routing assigned when a connection is requested and 
acknowledged, however, it will detect a failure if the connection is bad. Conversely, the 
Controller which made the requested connection has routing information, but cannot 
itself determine if the connection is actually operational without being told by the 
requesting TRAM. Similarly, the Controller cannot by itself determine when a failed 
connection has been repaired without first assigning it to a TRAM for use. Therefore, 
edge connectors previously marked as "bad" are periodically set to "good" so that they 
may be assigned and tested. A timer-based trigger is used to prompt the Controller to 
reset edge connector Status. 

Immediately within the WHILE TRUE loop is an ALT which guards both 
the pipe input and a boolean expression. The boolean expression evaluates to true when a 
predefined time period has elapsed and the number of failed link requests due to lack of 
edge connector resources has exceeded a predefined set point. Occam keyword AFTER 
is used to measure the delay from clock time now which was initialized when the 
program began, and reset when this expression evaluates to true. PLUS is a modulo 
addition operator which accurately adds clock times since timers recycle from maximum 
positive number to zero. The "&" is Occam boolean-and which requires both halves of 
the expression to be true for the entire expression to evaluate to true. Under normal 
conditions when no edge connector faults are reported, the expression never evaluates to 
true Since req.cnt never reaches the trip point (currently set at the number of TRAMs in 
the system). When many link failures are present, the timer delay prevents the expression 


from constantly evaluating to true and thus consuming too much CPU time. 


68 


(req.cnt > no.trams) & clock AFTER now PLUS delay 

When the combined expression evaluates to true, it signals a need to look 
for new edge connector resources. If too many edge connectors are marked as bad, the 
System slows appropmiately since the remaining connectors must be used for all like-link 
connections causing many link requests to be recycled as they wait their turn. If repairs 
are made to the bad wires, the Controller will not realize the status change unless the 
connection is reused by the TRAMs. Therefore, when many link requests fail due to lack 
of resources, the Controller looks for newly repaired edge connectors by periodically 
resetting their status to "good", thus making them available for use by make.conn as the 
need arises. If the connection is still bad, the status is reset accordingly. If the 


connection has been repaired, the status remains good until it fails again. 


D. TRAM MODULE 

Code on each TRAM is organized into five processes running in parallel and 
communicating via internal channels. Figure 4.4 shows the assignment of both internal 
and external channels to the TRAM processes with the configuration level link names 
written Outside the processor box and local channel names written on the inside. Note the 
division of the data link directions: data output is the responsibility of the Agent process 
and data input is received by the User process. Although each data link has its own 
Agent, it was not necessary to separate the User processes between the two links. Since 
the application code resides in User, the User processes could be combined into one 
process or connected via an internal channel so that the given application could have 
simultaneous use of both links. However, User processes were kept separate in this 


project to allow independent testing of both data links on each TRAM. 


69 


T800 | 


Manager 
mgr.toAm.agentO mgr.tofm.agent3 


link0.to.cO[stot] (Agents link3.t0.c1 [slot] 
gen 
mgr. 
user3 


agent0.toArom 
.userd 


link0.trom.c1 [slot] linkO.in link3.from.cO[slot] 


pipe(siot+1] 





Figure 4.4. TRAM Code Process Organization 











1. Manager Process 
Dedicated to managing the data link resources of the message exchange for a 
single TRAM, the Manager is connected via external links to the link control pipe, and 
via internal channels to both Agent and User processes on the TRAM. Since the code for 
the TRAM processes is replicated on each processor, two constants, slot.desig and 
no.trams, are passed to the Manager along with the channels. Slot.desig tells each 
TRAM which processor it is corresponding to the slot number in which it resides on the 


BO12. The slot number is also used to describe the data links: linkO of a given TRAM 
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equals the slot.desig, and link3 equals slot.desig+20. No.trams is a global constant 
telling the system how many processors are installed on the BO12, thus allowing crossbar 
connections only to existing processors. Manager procedure call is as follows: 

PROC manager (CHAN OF ANY to.pipe, from.pipe, 
mgr.to.agentO, mgr.from.agent0O, 
mgr.to.agent3, mgr.from.agent3, 
mar.from.user0O, mgr.from.user3, 

CHAN OF INT mgr.to.user0O, mgr.to.user3, 
VAL INT slot.desig, no.trams) 

Manager consists of an infinite loop monitoring all channel inputs, and a three 
stage control pipe output buffer running in parallel with the infinite loop. The buffer 
itself consists of three parallel processes, each as one stage inputting a three byte link 
command, source, and destination, then passing it to the next stage. The middle stage is a 
replicated parallel process allowing for easy increase in buffer size, however, testing 
showed that minimizing buffer size improved performance, and the smallest reliable size 
is three stages to allow room for continuous flow along the pipe. 

Immediately within the WHILE TRUE loop is an ALT which guards the three 
possible direct inputs to Manager: from either Agent or from the pipe. Each input is 
described separately below. 

a. Action For Input From Agent 

Either Agent communicates the needs of the application program via a 
single byte along the mgr.from.agent0 or mgr.from.agent3 channels. The byte re- 
ceived, one of several predefined byte constants for internal communication and 
contained in the intcmds library, is analyzed for further action. If the Agent signals that 
it is finished using an established link, Manager immediately sends a link release 
command to the pipe output buffer. Source and destination parameters with the link 


release are generated by the Manager since it knows which Agent is notifying completion 


(thus its link designation) and the destination to which it is still attached. 


ml 


Similarly, if the Agent reports a failed communicanon the Manager 
generates a link abort command along with source and destination byte and sends the 
command to the output buffer. For testing purposes, an additional command was added 
allowing an Agent to report its completion of data communications, thus allowing 
performance timers to record processing time. 

Finally, if the Manager receives a byte other than one of the predefined 
commands, the integer translation of that byte is interpreted to be a request for a 
connection to that link. Manager immediately sends a link request command, source and 
destination to the output buffer, and records the destination for use in generating 
subsequent commands. 

b. Action For Input From Link Command Pipe 

If neither Agent is communicating with the Manager, a three byte link 
command will be taken from the pipe input when present. The command byte is anlyzed 
to determine action to be taken, if any. A link request or release is simply passed along 
since it has not yet reached its final destination; the Controller. 

When a link acknowledge is received, the Manager determine its relevance 
to this TRAM by checking the source and destination bytes. If the destination byte 
matches a local link, that User is informed to expect receipt of data. The destination byte 
is then set to byte.nil for future reference and removal by a subsequent TRAM. If the 
source byte is local then the appropriate Agent is informed that a requested link is 
complete and to begin transmitting. Likewise, the source byte is then set to byte.nil. 
Finally, both source and destination are checked for content. If both are byte.nil, the 
entire three byte command is removed from the pipe. Note: this occurs even if both 


source and destination are local links, that is, the TRAMs linkO and link3 are connected. 
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Receipt of a link break is relevant to a TRAM only if the source byte is 
local. (The destination code in the User module which receives data input always 
monitors its channel, and need not be notified of connection creation or termination.) 
First, the local variable holding the address of the destination is set to byte.nil to update 
current status of connections. Secondly, the appropriate Agent is informed that the 
previous connection has been terminated and a new connection may be requested if 
desired. If either local link is involved, the command is consumed here, otherwise it is 
passed along the control pipe. 

If a link abort command is received, the command is immediately passed on 
if neither local link involved. Since aborts are originated by the source, the command is 
removed by the source upon its return, thus ensuring that both the Controller and the 
affected destination have seen the abort message. If a local link is the cited destination, 
the appropriate User is informed of the failed link by passing an integer along the channel 
used by the InputOrFail.c procedure to trigger a forced termination. A link reinitializa- 
tion will then be received, which informs the Agent and/or the User involved to 
reinitialize the affected link engine by executing the Reinitialise procedure. As with the 
acknowledge command, link bytes corresponding to local links are set to byte.nil before 
being passed on. If both source and destination are byte.nil, indicating the command has 
served its purpose, the command is removed from the pipe. 

Finally, other bytes passed along for testing or troubleshooting purposes are 
passed along without action, to be removed by either the Controller or by system 


monitoring code on the BO04. 
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2. Agent Process 

The name Agent was chosen for this process to signify its role: to act on behalf 
of the User in obtaining a connection and ee data. Once the Agent has instructions 
from the User, the User proceeds with the application while the Agent waits for the 
connection, passes the data block or recovers from a failed link. 

Like the Manager, the Agent uses several internal channels to communicate with 
the other TRAM processes, but only one external channel which outputs data to the 
destination via crossbars. Agent also receives a constant integer denoting its link 
designation. Header code for AgentO is shown; code for Agent3 is identical after 
changing the "0" identification to "3". 

PROC agentO (CHAN OF ANY mgr.to.agent0O, 
mgr.from.agentO, agent0O.to.userd, 
agent0O.from.user0O, link0O.out, 

VAL INT link.desig) 

Upon commencing execution, the Agent informs its User that it is ready to 
receive data for outputting. Agent then enters an infinite loop which monitors input with 
a PRI ALT from two sources: Manager or its respective User. The sequential actions 
from both code blocks is interleaved by message passing via internal channels. After 
initialization, the Agent sequentially: (1) receives data and destination from User, (2) 
requests a link connection via Manager, (3) receives notification of link connection and 
(4) passes data. If the connection is bad, the Agent: (1) informs Manager of a problem 
and recovers, (2) receives notification of link termination, (3) and finally informs User 
that it is ready to receive the next data and destination block. Note that the requested 
destination address is embedded as the first byte in the data byte received from the User. 
Use of the reinitialization procedures requires that data be passed as a block of bytes. 
However, Occam contains numerous retyping operators to convert a collection of bytes to 


and from other data types such as integers, reals, etc. 
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In the event of failed communication, the OutputOrFail.t procedure returns a 
boolean true in the aborted variable when the watchdog timer expires. This causes 
program execution to enter an IF construct which: (1) informs the Manager of link 
failure, (2) receives return confirmation then (3) proceeds to reinitialize the failed link. If 
the Communication terminates without failure, the Manager is informed of the request 
that the connection be terminated. 

3. User Process 

The third member process on each TRAM is the User, which completes the 
relationships and interactions described above. User code also contains all application 
code to be executed in the message exchange. For this analysis, dummy code was 
inserted to simulate a load on each TRAM processor and the resulting influence on 
system efficiency. That is, as the User module consumes more effort processing data, 
fewer requests for communications will be issued in a given time period. Conversely, 
User workload influences the performance of the other modules on the TRAM by taking 
more time slices to complete processing. 

User header code follows the patterns above with internal channels, one 
external data input channel, and two constant integers. 

PROC userO (CHAN OF ANY agent0O.to.user0O, 

agentO.from.user0O, mgr.from.userd, 
LinieOciny, 

CHAN OF INT mgr.to.user0, 

VAL INT link.desig, no.trams) 

User code consists of two WHILE TRUE blocks running in parallel. The first 
block is sequential code which manages data input similar to the output code used in the 
Agent. However, the User fault tolerant routines rely on external notification of a fault to 


terminate a failed communication by using the InputOrFail.c procedures. This notifica- 


tion is received from the Manager via the integer channel mgr.to.user. Accordingly, the 
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input link must allow for reinitialization with or without data being received along the 
link at the time of the failure. (Recall that in order to recover from a link fault, both input 
and output link engines on both ends of communications must be reset). Therefore, 
depending upon the command received from Manager, the link may be reinitialized at 
different points in the code. 

Application code is running in the second parallel block, which repeats a 
predefined number of times for testing purposes, each repetition generating and sending a 
new data block. This includes manipulation of data received, generation of new data, 
calculations and determination of destination to receive data. For this analysis various 
routines were used in different test runs to select only like-links or unlike-links, as well as 
simulating different degrees of load to be processed on the TRAM. A random number 
generator with a seed based on processor clock time was used to select the next 
destination when complete randomness was tested. Random numbers were generated 
until an acceptable link designation was established, which was then sent as a link 
request. 

4. TRAM Code Configuration 

To establish priority grouping of the five TRAM processes, the configuration 
code consists of a PRI PAR with a high priority PAR block nested within. The high 
priority block includes the processes which are crucial to external channel communica- 
tion: Manager and Agents. The low priority block for applications contains both User 
processes. Although this may appear at first glance to be counterproductive, significant 
gains are made in system performance by ensuring link control functions are conducted 
expeditiously. With different priorities, application code may wait unnecessarily while 
requested links are being created and terminated if there are excessive delays along the 


command pipe and output data links. 
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PRI PAR 


PAR 
manager () 
agentO () 
agent3 () 
userO () 
user3 () 


Processor configuration code also includes declaration of all internal channels 
used between the processes. Placement of channel names within parameter listings for 
each process connects the correct processes together. Also, integer constants are created 
in the configuration parameters. When assigning link designations to link3 processes, 20 
is added to the slot.desig value received by the TRAM from global configuration code. 

5. Global Configuration 

At the global configuration level, all external links are assigned to processor 
code, and processor code assigned to processors. As mentioned before, the TRAM code 
is replicated to each T800 processor on the BO12. Code replication is performed in the 
global configuration section. 

Two major blocks of code must be assigned to two different types of processors. 
Controller code is assigned to the crossbar controlling T212 Transputer, and TRAM code 
is assigned to one or more T800s on the BO12 motherboard. (Code for the monitor code 
on the B004 and its T414 is handled entirely separate from the message exchange code in 
an EXE fold). Transputer type is signified by the keyword T2 for T212 Transputer and 
T8 for a T800. This lets the compiler know which libraries are to be used in creating 
compiled code for each processor. To assign links, a set of constants 1s defined in the 
library links which also contains the constant no.trams. Link assignment matches the 
processor code parameter with the hardware link engine on each Transputer. Controller 


code header shown below is preceded by a one-to-one matching of software channel 
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name with hardware link component with the PLACE ... AT construct. The channel 
names are then matched to the procedure header definition in the local Controller code 


previously defined. 


PLACED PAR 
PROCESSOR no.trams T2 
PLACE pipe[0] AT link2in 
PLACE pipe[no.trams+t1] AT linklout 
PLACE t2.to.c0 AT linkOout 
PLACE t2.from.c0O AT linkOin 
PLACE t2.to.cl AT link3out 
PLACE t2.from.cl AT link3in 


controller (pipe[0], pipe[no.tramst1], 
t2.to.c0O, t2.from.cdO, 
t2.to.cl, t2.from.cl, no.trams) 
Similarly, the TRAM code parameters are assigned to hardware links, but a 
replication process is used to assign the same code with slightly different parameters to 
each T800. This is done by using an array of channels and carefully matching the correct 
array index with the replicated parameters. For example, to create the pipe each linklout 
of a given index value [slot] is physically connected to the next corresponding link2in of 
index value [slot+1]. This technique informs the software of the actual connections made 
with the BO12 hardware in a single statement instead of having to itemize the links of 
each processor. Each processor is also given a designation based on the incremented 
value of slot. Processor identification numbers are 100, 200, 300, ... for the T800 in slots 


zero, one, two, etc. Since slot varies for each replication, each T800 processor receives a 


different constant value for its slot designation and subsequent link designations. 
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PLACED PAR slot = 0 FOR (no.trams) 


PROCESSOR ((slot+1)*100) T8 


PLACE pipe[slot] AT linklout 
PLACE pipe[slot+1] AT link2in 
PLACE linkO.from.cl[slot] AT linkOin 
PLACE link0O.to.cO[slot] AT linkOout 
PLACE link3.from.cO[slot] AT link3in 
PLACE link3.to.cl[slot] AT link3out 


tram.code (pipe[slot], pipe[slot+1], 
linkO.from.cl[slot], link0O.to.cO[slot], 
link3.from.cO[slot], link3.to.cl[slot], 
slot, no.trams) 
As can be seen, all channel names used are declared strictly for the global 
configuration section, particularly those which are declared as arrays of channels. 


Correspondence with local channel declarations of the procedures themselves 1s achieved 


by correct placement of the parameters listed with the procedure call. 
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V. MESSAGE EXCHANGE PERFORMANCE EVALUATION 


Numerous test runs of the message exchange were conducted with variations in 
program structure and parameters. In general, each run consisted of 1000 link cycles 
(link control activity necessary to establish and terminate one link) performed 
back-to-back by each User. With four TRAMs in the system, a total of 8000 link cycles 
were completed in each run. The destination is chosen at random for each link cycle. In 
the unrestricted case, a User chooses from a set of seven possible destinations for each 
link cycle (excluding itself from the complete set of eight Users). When performance of 
only like-link or only dislike-link connections was studied, the User chose from a set of 
three possible destinations. All selections were uniformly distributed across the possible 
destinations available. Measurements include total time to completion, number of 
requests, acknowledges, breaks, aborts, and reinitializes needed. For various tests the 
system was run either loaded (with work simulated in the User process by adding a 
10,000 iteration SKIP) or unloaded and thus only performing link control and data 
passing activity. 

In the tables below each measurement is the average of five runs under the same 
conditions. Individual runs vary due to the random nature of the link destination 
requests, however, variations between runs are minor. Faults are introduced by providing 
Only one physical crossbar to crossbar edge connector for each like-link connection: one 
cable for linkO to linkO connections and one cable for link3 to link3 connections. In all 
fault-test cases the library tables incorrectly state that all 16 edge connector cables are 
available, therefore, faults are detected when the nonexistent cables are used. The two 


cables actually connected are the last two in the list, so the previous 14 must be identified 
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as faulty before the good cables are found. Additional faults are caused as known failed 
cables are arbitrarily reset in hopes of finding repaired cables. Also, additional link 
control commands are needed to accommodate simultaneous like-link requests since only 


one can be fulfilled at a time with the other request being recycled. 


A. DATA TRANSFER VARIATIONS AND SYSTEM EFFICIENCY 
1. Data Block Size 

Significant variations in system performance occurs due to data block size. Data 
block size must be defined at compile time due to the requirements of the link failure and 
recovery library procedures. Once selected, the data block size remains fixed for the 
duration of program execution. Therefore, if the application program expects to transmit 
variable length data between nodes, the block size must be chosen to allow the maximum 
expected data length, with extra bytes in shorter messages being discarded. Test 
measurements were collected with data block size varying from two to 8192 bytes in 
factors of two. The upper limit of 8192 bytes was reached due to the memory available 
on each TRAM (36 kilobytes total of on and off-chip RAM) and the declaration of arrays 
for both output and input data blocks by each user. 

Tables 5.1 and 5.2 provide the results of testing the unloaded system with and 
without faults, and Tables 5.3 and 5.4 with simulated system load. Time to complete an 
8000 request cycle run increases with data block size, but not significantly until block 
size reaches 64 bytes in the unloaded runs and 128 bytes loaded. The relatively 
consistent execution times for smaller data block sizes represents the time to route link 
control information and perform the action required for link operations. Actual process- 
ing and data passing performed by Users easily fit within the gaps formed by high 


priority Agent and Manager processes concentrating on link control. 
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Raw data measured and listed below includes execution time, number of 
requests and total link control commands used as averaged over five runs of identical 
parameters. Calculations which compare number of data bytes take into account the data 
block size and the number of data blocks passed: 8000 in all runs. Calculations involving 
link control bytes take into account that each command consists of three bytes and the 
number of link control commands issued (either requests only or the sum of all six 
command types, as specified). Calculated figures listed include microsecond per data 
byte passed, average number of requests needed for the per data byte passed, data transfer 
rate in kilobytes per second (inverse of microseconds per data byte, adjusted for change 
in units), a ratio of data bytes to control bytes, and control communications overhead as a 
percentage of link control bytes passed of the total bytes passed in the system. 

The single T212 link controller also represents a limiting factor, particularly 
when processing a request for a like-link. During the T212’s execution of sequential link 
manipulation code no additional link control commands are received causing the pipe to 
fill. As each TRAM?’s buffer fills, no more control commands can be submitted or 
received by the Managers on subsequent TRAMs. This ripple effect continues and 
prevents Agents and Users from proceeding to the next data transmission. Although it 
may be possible to implement the T212 code as a collection of parallel processes with 
One being an input buffer, such constructs consume considerable amounts of memory. 
With only two kilobytes of on-chip RAM and no off-chip RAM available, every effort 


was made to minimize T212 code size. 
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TABLE 5.1 


SYSTEM PERFORMANCE DATA: UNLOADED, NO FAULTS 





TABLE 5.2 
SYSTEM PERFORMANCE DATA: UNLOADED, WITH FAULTS 


Total 
Link 
Control 


90.19% 
82.17% 
69.72% 
53.77% 
37.09% 
23.16% 
13.54% 
7.77% 
4.60% 
3.01% 
2.10% 
1.72% 


B10 700 1.51% 
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TABLE 5.3 
SYSTEM PERFORMANCE DATA: LOADED, NO FAULTS 


Time | Number 
(Sec) Of 


Olea 





TABLE 5.4 
SYSTEM PERFORMANCE DATA: LOADED, WITH FAULTS 


Time | Number 
(Sec) Of 


86.20% 

75.72% 

60.92% 

43.84% 

28.20% 

16.44% 

9.06% 

4.90% 

2.80% 

1.56% 

Lise 

; 1.05% 
221,866 ; 1.11% 
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Also of concer is the BO04 and T414 monitor Transputer. Excessive work by 
this Transputer would also have a slowing influence on the link control pipe. Several 
variations of BOO4 code were used with widely varying degrees of complexity. Timing 
differences between the simplest T414 code and the monitor program used were 
negligible. Also, both input and output buffers were added as part of the T414 code to 
help smooth its presence on the pipe. 

Figure 5.1 shows the effect of data block size on execution time. All four 
combinations of load and fault status are shown. Note the minimal difference between 
the runs with and without faults. With any number of TRAMs in the system, the 
minimum number of good edge connectors needed is two; one for each type of like-link. 
Less than one link would result in failure to pass any data between like-links, thus 
causing affected processes to hang. However, with four TRAMs the minimum needed to 
obtain fault free transmission is four; two per like-link type. Therefore, the differences in 
the number of edge connectors in these runs is only a factor of two, and does not 
significantly stress the system since the simultaneous need for two like-link connections 
is relatively rare. 

As data block size increases beyond 128 bytes the control pipe and T212 are no 
longer bottlenecks. Sufficient time is spent by each node in creating and passing data that 
link control commands enter the pipe with minimal restriction. Consequently, links are 
terminated in a timely manner allowing the next request for those resources to be fulfilled 
in the first attempt without recycling the link request. Worst case performance occurs 
with the smallest data block size and unloaded User processes. Since no application 
work is done by unloaded Users the performance data is used for comparison as a 


baseline. 
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Tables 5.1 through 5.4 show increases in data communication rate with block 
size, but the rate does not double as block size. Although more data is transferred in 
larger blocks, the system must work harder to establish the requested connections since 
resources are held longer. Without a quick turnover of resources to the next requesting 
node, link control information is recycled back into the pipe for a later try. The number 
of link requests increases dramatically with block size showing the difficulty in achieving 
the requested connection. Therefore, greater link control overhead reduces system 


efficiency when block size becomes too large. 
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One way to show this is to compare data bytes versus control bytes, noting that 
each control command consists of three bytes. Figure 5.2 shows the data byte-to-control 
byte ratio and the loss of communication efficiency encountered when data block size 
becomes very large. In the unloaded tests, as the block size is increased beyond 1024 
bytes the data-to-control ratio (and hence, system efficiency) still increases but less 
rapidly than with block sizes below 1024 bytes. As data block size is increased beyond 
4096 bytes, the data-to-control ratio actually decreases. The loaded case shows a similar 
affect, however, since fewer control communications are needed the decrease in 


efficiency will take place at higher data block sizes than practical to test. 
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Figure 5.2. Data-To-Control Communication Ratio 
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Efficiency comparisons using control and data communications are not the best 
indicator of performance since each link’s DMA engine proceeds with only minimal 
effort of the system CPUs. Although the use of DMAs is especially beneficial in passing 
large data blocks, system burden increases when all CPUs in the control pipe are passing 
small commands. Using the execution time of the unloaded runs with small data block 
size as a base time gives a better comparison of system overhead resulting from link 
control operations. As discussed above, no significant change in execution time occurs 
until block size exceed 64 bytes. Therefore, execution time of small block size runs 1s 
predominantly a measure of link control effort of the system. By averaging the execution 
times for two, four, and eight byte block sizes of the unloaded runs a base execution time 
for the system 1s established. 

Figure 5.3 shows a ratio of base execution time versus execution time of larger 
block sizes in both loaded and unloaded runs. Worst case, of course, 1s small block size 
on an unloaded system. Control overhead drops off sharply as block size is increased 
beyond 128 bytes. In the loaded system, overhead starts at about 25% and decreases 
slowly as block size increases until approaching the unloaded overhead at a about 8% 
with a 8192 data block size. Control overhead for systems with load less than the test 
load will plot between the test load and the unloaded system results. Only measurements 
of runs without faults are shown for clarity. 

2. Data Routing Via Multiple Crossbars 

Separating each TRAMs data links into individual User processes allowed 
analysis of the affects of different routing paths. Due to the wiring arrangement between 
the crossbars and the TRAMs, the methods used to connect like-links is significantly 
more complex than connecting a linkO to a link3. Additionally, the slowing influence 


associated with multiple C004 crossbars is a concern in like-link connections. 
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Three sets of runs were conducted under varying constraints limiting the routing 
assignments. For each of three data block sizes: 8192, 1024, and 128 bytes, a set of runs 
were conducted under normal routing (uniformly selected from all seven possible 
destinations), with only like-link routing and with only dislike-link routing (each 
uniformly selected from the appropriate subset consisting of three possible destinations). 
Table 5.5 below shows the results. 

As can be seen from the data, the large data block size of 8192 blocks causes an 
increase in required time when routing is restricted to only like-link (two connections per 
crossbar) as compared to the case in which routing is restricted to only dislike-links (one 


connection per crossbar). This result is not as pronounced in the 1024 byte block and 
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even less with 128 byte block. Figure 5.4 shows a comparison of the three link 


restrictions and three data block sizes, normalized to the random link type of each block 


S1ze. 


TABLE 5.5 


LINK ROUTING ANALYSIS RESULTS 














MESSAGE SIZE: 8192 


Execution Time (seconds) 
Number of Requests 
Total Control Commands 
Time(usec) / Data Byte 
Requests / Data Byte 
Kilobytes Data / Second 


MESSAGE SIZE: 1024 


Execution Time (seconds) 
Number of Requests 
Total Control Commands 
Time(usec) / Data Byte 
Requests / Data Byte 
Kilobytes Data / Second 


MESSAGE SIZE: 128 


Execution Time (seconds) 
Number of Requests 
Total Control Commands 
Time(usec) / Data Byte 
Requests / Data Byte 
Kilobytes Data / Second 
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45.706 
160,311 
184,311 
0.6974 
0.0024 
1400.3 


17.682 
16,625 
32,625 
2.1584 
0.0020 
452.4 


14.7788 
9,427 
25,389 
14.4324 
0.0092 
67.7 
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48.137 
203,743 
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0.7345 

0.0031 
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17.7562 
18,558 
34,558 


2.1675 
0.0023 
450.5 
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14.7442 
9,617 
25,617 
14.3986 
0.0094 
67.8 
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0.0092 
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B. TRAM CODE STRUCTURE 


Considerable influence upon performance can result from slight changes in an 


Occam program structure. Timing and CPU utilization are changed when different 


priorities are assigned to parallel (PAR) processes. The TRAM code is subject to these 


considerations and various configurations and their effects are discussed below. 


As shown earlier, each TRAM contains five processes executing in parallel and 


communicating with each other and with other processors (see Figure 3.7). Atkin 


[Ref 10:p. 12] stressed that efficient code must be structured to separate as much as 


practical those processes performing communications from those performing calculation. 
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This is accomplished in the TRAM by placing all application calculation in only the User 
modules. When data is to be passed to an external destination the data is passed to a high 
priority process dedicated to outputting that block along a link. 

Communications processes should be run in high pnonty to help ensure that the 
communications themselves do not become a bottleneck in holding up information flow. 
Prompt initiation of communications also sets in action the DMA link engines which can 
then release the processor to perform other work. Given this guidance, it is clear the 
Manager process must be run at high pnority to handle all link control communications 
and the User processes must be run at low priority to perform application work and data 
input. Different configurations were tested adjusting these priorities. Performance of the 
configurations varied widely; some resulted in nonfunctioning programs due to commu- 
nications starvation. For example, running the User processes in high priority and the 
Agent processes at low pniority resulted in deadlock. 

Three configurations were tested and compared under unloaded and loaded condi- 
tions using a 1024 data block size. The normal case consisted of the process prionity as 


listed in the presented code. Case I and Case IJ are listed below: 


Normal: Case I: Case II: 
PRI PAR PRI PAR PAR -- low 
PAR -- hi Manager () -- hi manager () 
Manager () agentO () -- low agentO () 
agentO () agent3 () agent3 () 
agent3 () user0O () userO () 
--low user3 () user3 () 
user0Q () 
user3 () 


Comparisons of the three cases are shown in Figure 5.5. Separate tests were 
performed with and without simulated load in the User process. All figures are 


percentages normalized against the appropriately loaded normal case. 
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C. LINK FAULT RECOVERY PERFORMANCE 

When a link fault occurs a minimum of three additional control commands are 
issued: link.abt, link.rei and link.ack (see Figure 4.1). If a replacement route is not 
available either due to lack of "good" edge connectors or all routes are busy, a link.req 
will cycle in the control pipe as in the non-fault case. If other faulty edge connectors are 
inadvertently assigned (having not yet been discovered as faulty), the abort message 
chain will repeat until a good route is found or a cycling request is issued. 

After the Controller has determined a valid status for all 16 edge connectors the 
abort message chain should occur once for each new request resulting in an abort due to a 


newly created fault. However, as the req.cnt increments when the Controller realizes a 


oe 


resource shortage, previously identified failed edge connectors are reset allowing them to 
be reassigned in the hopes of locating repaired cables. Two variables control the 
periodicity of resetting edge connector status: req.cnt upper limit and delay time value. 
For this project the req.cnt upper limit was set equal to the number of TRAMs in the 
system (four) and the value for the delay timer was set to 16000 ticks of the low priority 
clock, or about one second. Use of the counter prevents unnecessarily resetting edge 
Status without need, and the timer minimizes repeated resettings when the need for new 
resources is great. Both values can be adjusted accordingly to adapt system performance 
to the application implemented. For example, a shorter time delay would quicken the 
Controller’s ability to find newly repaired edge connectors. 

Execution time affects fault recovery actions since as the system operates longer 
under fault conditions, more previously identified faulty edge connectors will be reset 
based on delay time. Data block size does not directly affect the degree of additional 
workload resulting from the presence of link faults. However, in the test cases run the 
use of larger data blocks increases the total amount of data transferred, thus increasing 


total execution time and, consequently, the number of fault recovery communications. 
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TABLE 5.6 
PERFORMANCE ASPECTS OF FAULT DETECTION AND RECOVERY 


System Unloaded System Loaded 


Data No. Of Added Comms No. Of Added 
Block Aborts Total Per Aborts Total 
Size Comms _ Abort L 


SE ———— — 







Zz 778 
4 867 
8 856 
16 , 843 
oy OFF 
64 lehlS 
128 974 
256 1,224 
S12 1,828 


1024 2,400 
2048 2509 
4096 9,310 
8192 21,786 


1,674 
1,128 

6,378 
20,888 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

By using specialized though off-the-shelf hardware, a dynamically reconfigurable 
network of Transputers can be constructed. The Transputer’s unique link hardware 
makes this single-chip processor very appropriate for this type of system. Efficiency of 
the message exchange presented here is largely determined by data block size and the 
application load on each node. System control overhead is minimized by keeping the 
link control commands small and infrequent. As a dynamically reconfigurable system, 
this message exchange evaluated the worst case scenario of requesting and establishing a 
new connection for each data block passed. A semi-static configuration system, which 
reconfigures the network topology only at synchronized points during application 
program execution, would improve system efficiency by reducing overhead at the 
expense of reconfiguration flexibility. 

A concept implemented in hardware should have superior performance over the 
same concept implemented in software. In this case, use of program controlled crossbars 
to directly connect communicating nodes should perform comparably well or better than 
a packet routing system which passes data through intermediaries. However, gains made 
in the direct routing of data are offset by losses incurred in routing crossbar control 
information. Utilization of a link control pipe to pass control information from node to 
node diminishes some of the gains achieved from direct data connection. An ideal 
correction to this drawback would be to pass link control information point-to-point, 
comparable to the manner in which data is passed. One method for implementing 


complete crossbar connectivity is described in the Esprit Project [Ref 24] in which all 
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four links of each Transputer are connected to large crossbars. Thus far in the Esprit 
Project semi-static reconfiguration is implemented, and use of specialized hardware 
allows for increased expandability. 

Techniques explored in this paper stress the circuit switching approach made 
possible with readily available hardware, including program controlled crossbar switches. 
Considerable commercially available hardware also exists employing packet routing 
methods, most notably hypercube parallel processors. Hypercube topologies maximize 
performance by symmetrically interconnecting nodes to minimize the distance between 
any pair of processors, thus reducing packet routing overhead. A hypercube topology 
contrasts the message exchange developed here by substituting crossbar control overhead 
with packet routing overhead. A key parameter affecting performance in both topologies 
iS message size, which is determined entirely by the application to be executed. A 
performance comparison between the two methods should be conducted by executing 
identical application code in each topology. Since the number of nodes in a hypercube is 
equal to two raised to the nth power, where n is the number of links available to each 
node, a 16 node hypercube could be readily constructed using Transputers. This 
Transputer hypercube can be evaluated against a 16 node message exchange implement- 


ed ona fully populated BO12 motherboard. 


B. RECOMMENDATIONS FOR FOLLOW-ON WORK 

Integrated shipboard weapons systems of the complexity found in AEGIS consist of 
a collection of specialized computers distributed throughout the weapon platform and 
communicating with each other as necessary to detect, identify, track, display and direct 
the weapons’ fire towards targets. Although the processing power is distributed among a 
number of processors, the specialization calls for discrete elements of processing power 


to be assigned to specific tasks. Communications within each group as well as between 


i) 


groups need not be completely dynamic nor be able to achieve any arbitrary topology. 
However, some reconfiguration ability would be invaluable as the system posture 
changes or in response to faults occurring in the system. A posture change of the 
weapons system could result from refinement of the tactical environment, for example, as 
the potential source of the current threat is narrowed to subsurface as opposed to 
airborne, appropriate computing resources can be directed to concentrate accordingly. 

Given this dedicated grouping of computing resources, an architecture similar to the 
BO12 can be employed at each specialized station. A collection of Transputers with 
dynamic reconfiguration could adapt to system load changes as well as the occurrence of 
local faults. Interconnection between stations can be achieved by using switchable links 
of the crossbars accessible at the edge connectors. A hierachy of control would be 
established between stations using a inter-B0O12 link control pipe separate from the 
internal pipe developed here. Again using the BO12 as an example, the TRAM in slot 
zero can readily be disconnected from normal C004 crossbar connections, thus freeing a 
significant processing resource to direct interstation communication control. 

Figure 6.1 shows an arrangement of BOQ12 stations with an additional link control 
pipe using the slotO TRAM of each station. Data connections between stations can be 
hardwired between the remaining crossbar links not used for the local TRAMs. 
Assignment of these external links can be weighted in favor of the most needed 
communications routes, with additional links assigned for redundant communications 
paths thus allowing for interstation link fault tolerance in a similar manner as demonstrat- 
ed on the single BO12 in this project. Interstation link fault tolerance would become 
especially valuable when considering various battle damage possibilities throughout the 


ship as well as equipment failures. 
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Figure 6.1. Multiple B012 Connectivity And Control 


Link control communications overhead will always be a factor limiting efficiency, 
however, if reconfiguration is a rare event then control signals will be minimized as 
compared to a completely dynamic and therefore worst case system in terms of overhead. 
Also, if the processing power of a given station must be increased, or if more external 
links must be added, two or more B012s can be arranged head-to-tail to extend the local 


link control pipe thus increasing the number of local TRAMS as well as crossbars. 
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Although Transputers are an extremely capable computer component, the above 
discussion should not be taken to imply that a complex integrated weapons system can or 
should be implemented in the off-the-shelf technology as described in this thesis. 
However, simulations and modelling of system functions and interactions can be 
implemented as described. Link connections can relay simulated sensor information as 
input to One station, environmental and real-world simulation to another, weapons 
response to a third, and so on. Additional stations can output commands to weapons’ 
control as well as tactical displays and communications. As a modelling tool, Transput- 
ers can be used to test and optimize system software and hardware topologies, and to 
identify and test the specialized hardware necessary to meet the high performance needs 


of a modern weapons system. 
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APPENDIX A 
MESSAGE EXCHANGE LIBRARIES AND SYSTEM CODE 


cm re rr wr rw ww rw ia i LS 
me ww ww SS SS SO LS 


-- DATA LIBRARIES used in BO12 Message Exchange 
-- All libraries stored in same directory 


cm mm ww a i828 8 SS SS 
cmt cc cre cr cr cr cr cr cr cr cc cr cr ce cr ce mc cm cm cr cc cc ee ee ee ee ee ee ee ee ee ee ee ee ee ee eee eee eee 


Veo linkOeut IS 0 -- standard link definitions 
VAL linklout IS l 
Valen kZout 1S *2 
Weeelink3sout 1S 3 
VAL linkOin IS 4 
Pee tainklin IS 5 
WeinelinkZin iS 6 
Valieelink3in IS 7 

4 


VAL no.trams IS -- number of TRAMS on BOQ12 


ce ee ce cc cee ee ee ee eee ee eo eo ee eee eee eee eee ee 


VAL c4.input.output So SOG Y aE): 
ve c4 . link PSaeis “(BY Es): 
VAL c4.enquire TS] Cen Yeh: 
VAL c4.setup 1S 3) 30BnehE >: 
VAL c4.reset TS 4 50B Ter ):: 
VAL e4. disconn. output ism Ss (US) Cig 
tai G4.diseonn. Link TS AG™BYTE) : 


VAL link.req DES) CG CPOS AN) Jbl jel ne Vonmalte) oy 

Mat, bink ack cS eee) EO Genero: pipe 
WALL Unk Ge Ss 42° (8yYre): 

VAI | ink ee LS “4 30tey TE): 

VAL link.abt TS cee TE ) : 

WAL tink trem tS 43 (BYTE): 


VAL block.size Ls 6 (eee: —-oveEes 
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—em ame ae cee qe cee cee ae ae cee eee cee see cee eee eee ee ee | =| ew see Ee aE aE aE aE as a Bean eamBamramamram SB awe aw ae aE ae aS aT as ae aes ae ae ae ae ae aa 


-- intcmds - defines other internal commands used 
i - and link trans latwermmerable 


=— oemwemw @Barmramwramwawa=e SB ae eawBawe—weamweamramramramramramrarmramamamawmamamwarm BZ a= oP eaweamweanweenmremrenweeamwreaweerwraweemweeamweamwoawewenwr ee ee ee ae aa aw = a= a= == 


VAL failed IS 60 (BYTE): -- predefined values 
VAL reinit IS 61 (BYTE): -— sional” temeescee 
VAL done.with. link 1S 63 (BYTE): =="“oeutpue ers deme 
VAL all.done LS .6 5.0 (BY ene: = eae eee nie 

VAL ready tO. bew IS 67 (BYTE): -- Agent temUser 

VAL link.made TS.68 (BYTE): -~saMorstomAgemnte 

VAL link.gone IS 69 (BYTE): -="Mgr to Agene 

VAL byte.nil IS 9S) (BYTE) eee de fine 

VAL BOOL otherwise irs TRUE ==" fOr PF semw@s 

VAL INT user.failed LS a6 Ome: —- for fault recorerny 
VAL INT uSer.reinit LS. 6105; =-=- Mgr to User 

VAL INT user.linkmade Seo cue: -- Mgr to User 


-- array to convert C004 link number to Ji1nk0=ons = eaten 
S low 
== index O0=3) for 764 links 0-50 
== data INT 15 980415 for Trams 20= (5 e017 
-- 20-35 for Trams ~“0=)5 Jie 
VAL [32] INTE St6 +s Poems 
[uaz = 25ooeeeeeeeS, 26. iy Sa Alay 

TS pS, S55, 5 eel ZS ecole 

T jee Sy U4 > AB ZT ee oe ee Or 

343) te Awls, Ss Oe 29 3 Ore EO] 


—sn ewer eww sw ee Ss ae ew Tew ow ewewesw es SBP eawPeawawewew ss ewer awmrewmwenwmwaewr aweewmwemewenmweewewemewemweawe a= ee aw ee ae a= oe ae = awe aweaw a= a= a= 


-- number of connections suitable for 0 to 0 links 
VAL INT edge0O.ct IS 8 

-- number of connections suitable for 3 to 3 links 
VAL INT edge3.ct IS 8 : 


-- each edge.a[x] 1S manually patched to edge.b[x] 

VAL edge.a IS [ 4(BYTE), 6(BYTE), 31(BYTE), 25(BYTE), 
19 (BYTE) , Were) be S{BYTE), l2 (BYE 
OB Yarsie IX BYTE), Z9(BYTE), 24 (BY ae 
17 (BYTE), 21( BYTE), LO (BY tr) 4 CB eee 


VAL edge.b IS [ °S(BYTE), 3(BYTE)3e 26427 0B go eran 
Z22(BYTE), 18(BYTE), “S(ByYtEye loth ane), 
Z(BYTE), 7(BYTE), 3SO0BYTE) = 2/7 (evil 
23 (BYTE), 20 (BYTE), 13 (Bee Gee 
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cr mr rr cr cr rc cr ac rm mr mm ccm cr cr cc ce wm ee ee iw i i 
—sw ec cm mc cr rm rm rm rm rm mc cr cr cr cr cr cc ce ce ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ie i ee 


-- BO12 Message Exhcange w/2 C004’s & 16(max) TRAMS 
=-m@ocde for T2l2 Crossbar Controller 
-- Note: B0Q04 monitoring code is seperate 


ec mr mm rm rm mm ws rm me ww ws wm mm mm rm mw ww we i 
sr ce ce me mm me re er rr ce ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ce ee ee ee ee ee ee ee ee ee 


PROC controller (CHAN OF ANY from.pipe, to.pipe, 
Gamers ron.cU,. FCO.Cl, from.ci, 
VAL INT no.trams) 


meat a lider auayvaa@e ]jys 
$0SE “c4cmds.tsr" 
“oo, “Cerlemads.tsr™ 
OSE weit Crdset sr" 
#USE "“edgedata.tsr" 


VAL delay IS 16000 : -- pause in status reset 
BYTE token, Source, dest 
Brel SrTC.cOnn, dSt.conn. : iio lS eeu mreine 1G Okt Ss 


BOOL continue, accomplished 


{16]BOOL edge.ok : -- edge status array 
INT i, now, edge.index, req.cnt : 
MmevBR clocks: -- timer for edge reset 


=-woubroubame EO Ssetea link to nil if inactive, 
== or reset high bit to low if active 


PROC reset.or.nil (BYTE c4link) 
LE 
-- if high bit is set (link is acitve) 
((INT (c4link))BITAND(INT(BYTE #80)))=(INT(BYTE #80) ) 


-- then reset high bit to low for valid link number 
c4link := BYTE((INT(c4link)) >< (INT (BYTE (#80) ))) 


otherwise 
-- high bit is low therefore link is NOT active 
c4link := byte.nil 


-- end of PROC resSet.or.nil 
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PROC c4.cmda (CHAN GE SAliveeo7 ote 
VAL BYTE emd, bl, 62, BYTHw@ss) 


SEO 
IF --~ determine command to use 
cmd = byte.nil =—- just do enquire 
SKIP 
bl = byte.nil -- Single parameter command 
GO. x. emess bz 
otherwise 
EO. x @eemd; bil; soz -- two parameter command 
to.x ! .e4 lengua re mez -- verify action by enquire 
EMex 2S 


reset.or.nil (b3) 
=——S6newee 164 ene 


-- Subroutine to get %eWmpent Connect tcmre 
== requested hookup. All i/o in c4 link desigs 
PROC get.current.tie (CHAN OF ANY to.c0O, from.c0O, 
CGsel.- frome 
VAL BYTE in.link, BYTE link.tied.to) 


-- Note: all Bytes in terms of C004 Link designations 
SEO 


IF -- determine if in.link is already connected 
in.link = byte.nil 
SKIP 
ESSE slot [INT (an wk Ga) -- it is a link0O 


= get input link “(2E any) ecenneceea toma. link 
a cmd (towel, from.¢l Ove omnis im erepeel, 
Se iliac, jae Ha ce) 


EO Slot [INT(in.link)]) > (19)) -- it is a link3 
- get input link (if any) connected ome link 
c4vemd(to.c0, fremre0? byte mil byteuem,, 
Pea leis coc 


otherwise 


SKIP 
-- end of get.current.tie 
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-- Subroutine to make a connection between two C004 links, 
== veirfy connection is made, and return status flag 


ao oveeMake eommm (CHAN OfmaNnyY Cto.cOvrrom.c0,to.cl,from.cl, 
VAL BYTE source, dest, BOOL conn.ok) 


PROC make.0033 (CHAN OF ANY to.a, fm.a, to.b, fm.b, 
VAbeaile Sree, ast, 
VAlepeor link surou,. BOOL connd03.ok, 
BYE a, hme) 


BOOL edge.used 
INT index, max.index 
Bi eInpuedea, inputbb 


SEQ -- select appropriate index ranges for link 
102 
link. 0to0 
SEQ 
index := 0 
max.index := edge0.ct 
otherwise 
SEQ 
index := edge0.ct 
max.index := edge0O.ct + edge3.ct 
edge.used := TRUE 
WHILE (edge.used AND (index < max.index) ) 
IF 
edge.ok[index] -- edge 1s still "good" 
SEQ 


c4.cmd(to.a, fm.a, byte.nil, byte.nil, 
edge.a[index], inputaa) 

c4.cmd(to.a, fm.a, byte.nil, byte.nil, 
edge.b[index], inputbb) 


Ik 
((inputaa = byte.nil) AND 
(inputbb = byte.nil)) 
SEQ -- if edge not currently connected 
edge.used := FALSE 
CACC EO dyad C452nput.output, 
src, edge.a[index], in.a) 
Cimcnd (=O ve, wens, Co Input. output, 
edge.b[index], dst, inputbb) 
e4neme eG wageeemeayec4. 1Nput.cutput, 
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dst, edge.b[index], in.b) 
c4.cmd(to.b, fmebDae C4eeinputeeume pute 
edge.a[index], src, inputaa) 


3m 

((inputaa = edge.a[index]) AND 
(inputbb = edge.b[index]) ) 
conn03.0k := TRUE 

otherwise 
conn03.ok := FALSE 

otherwise 
index := index + 1 -- busy, try Next 
otherwise 
index := index + 1 -- get next edge, "bad" 


-- end of make.0033 


-- Main Section for PROC make.conn 
BYTE linka, Jinkb, “anpuea, | encuey 
BOOL crosslink.ok 


SEQ 
crosslink.ok := TRUE 
-- make linka linkO of two to be connected if other 
-- is link3. 2 bothelink® “ss ss ne enaeeen 
1a 
((to.slotLINT (source) 4m -aelo) 
SHO 
linka := source 
linkb := dest 
otherwise 
SEQ 
linkb := source 
linka := dest 
ie 


16)) AND 


(( (tosshotll int (linmkael)) <a 
Set EO) 


((to-slToewentT (ibmnikea)) 
SEQ 
c4.cmdjto.c0, from: CU wea neut . OuUEDUE, 
linka, linkb, inputa) 
c4acmd(to.cl, Erom. cl? e424 ameut .output, 
linkb, linka, inputb) 


(((to.slot [INT (linka)]) < (16)) AND 
( (GogsVer | INT GeimikbD) pip eicesGls) )) 
makewO033tweeccO, fromec), Eoscl fc om. © lam anicar, 
liankb, TRUE, @ crosslink. OK) = 1npula melnmuiel: 
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(( (Govslot (ENT (Pama) | ) 19) ) AND 
(CEO. Stet LINT Gamage > (19))) 
Make OUse  (cOweeimemecl!, tOo.c0O, “romreO, linka, 
linkb, FALSE, crosslink.ok, inputa, inputb) 


otherwise 
SKIP 


-- verify return input eng bytes match (high bit set) 
TF -- links match, connected ok 

(((linka = inputa) AND (linkb = inputb) ) 

AND crosslink.ok) 


conn.ok := TRUE 
otherwise -- links are not made 
conn.ok := FALSE 


-- end of make.conn 


-- Subroutine to brk a connection between two Tram Links 
== (may involve as many as 4 C004 links) 
-- veirfy connection is broken, and return status flag 


PRO@, Dreak.conn (CHAN OF ANY to.c0, from.cO, 
EO. Clg nt bOMNeel, 
VAL BYTE source, dest, BOOL broken.ok) 


VATE BY Davesme, ast, 
BYTE in.a, in.b, BOOL break03.ok) 


BYTE edgea, edgeb 


SE 
-- get edges used 
to.a ! c4.enquire; sre 
fm.a ? edgea 
to.a ! c4.enquire; dst 


fm.a ? edgeb 

-- disconnect the edges 

e4end (EGRb Orlane eo CUSconnoukpur, byte.nil, 
edgea, in.a) 

e4 2 emer. 5,) itive mice Mcmesa@onmemourputL, byte.nil, 
edgeb, in.b) 


Vide 
((in.a = byte.nil) AND (in.b = byte.nil)) 
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breakU03 sok :— [RUe 
otherwise 
break0O3.0k °= FALSE 


c4.cmd(to.a, fm.a,se4edisconn{cultpubaeeyreoam |: 
SEC, ina) 
c4.cmd(to.a, fm.a, e€4-daisconnwouepuc, Syren -, 
dstyain.. b) 
-- end of break.0033 


-~- Main Section of PROC break.conn 
BYTE linka, linkb? Sinputa wanpies 
BOOL edge.free 


Sa. 
edge.free := TRUE 
IF 
((to.slot (INT tsounec) ps1 6) 
SEQ 
linka := source 
linkb := dest 
otherwise 
SEQ 
linkb := source 
linka := dest 
Jide 
—-— break’ a tram Dimi 0 Beomessane la micns 
(((to. slot [INE G@binka) |) ) =o “AND 
((€o. Slot (INT inks) | ae ee) 
SEQ 
c4.emd(to.cl, from.cl, G4eaiceconnmeonrener 
byte.nil, linka, inputa) 
c4.cmda(to.c0O, fErom.c0, 4eecusconn.outpum 
byte.nil, linkb, inputs) 
(({to.slot [INT (linka) }) = (ise pian 
((to. slot (INT (links) } =< (Giese 
break.0033 (to.cl, fvomecl, Comeure fponseu, 
linka, linkb, inputa, inputb, edge.free) 
(( (Ce SlLOE TINT (linkaly > oy) ec 
( (to. slow In’ (amke ya) Soe) 
break.0033 (to .e0, Eromect. comely. rom. c., 
linka, linkb, inputa, inputb, edge.free) 
otherwise 


Sedge 
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=- Verity broken Panmemaumeactactive (high bit off) 
Jus 
-- links verified broken 
(((inputa = byte.nil) AND (inputb = byte.nil)) 
AND edge.free) 


broken.ok := TRUE 
otherwise 

-- links not broken 

broken.ok := FALSE 


== ©8nq Of Dreak.conn 


i —= — — = — — es ee es cs ee "es — —_ — — — — — = — — 
=: ee i ce Oc ace ™ =o — _= = _ — — — <= a_ ae ™ a= _ — = — —_— —_ _—_ — 


SEO 
= itTteializat lem 
~O.cO ! «4mreset 
mo.c! |! c4 reset 
SEO 1 = OFFOR 16 


edge.ok{1] := TRUE 
edge.index := 0 
clock ? now 
GBecceme . = 0 
WHILE TRUE 
ALT 
From, P1lpe MeTOKeEN; msoumr Ceres dest 
SIRE, 
1S 
token = link.reg 
SEQ 


Fete cumaeci@mete (tO.cO, from.cO, to.cl, 
PeeneecmeesOurce, src.conn) 

Ceenetmrenm tre =(Eonecur f£rom.c0, to.cl, 
ErOmuew oest, ast.conn) 


IF 
((srce.conn = byte.nil) AND 
(St -conn =ssovyee.nil)) 
-- connections free, make the request 
SEQ 
Meacemecenn(to.cu, from.c0O, to.cl, 
from.cl, source, dest, accomplished) 
ile 
accomplished 
SEO 
-- conn made OK, send ACK 
to.pipe ! link.ack; source; 
dest 
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otherwise 
SING) 
-- for whatever reason, no go 
to.pipe ! link.req; source; 
dest 
req. cnt ‘S= req zene joa 


otherwise -- repeat request later 
to.pipe ! link.req; source; dest 


token = link.rel 
-- break an existing connection btw 2 Trams 
sya.) 
break.conn(to.c0, fromsc0, to.cl, frenmew 
source, dest, accomplished) 


IF 
accomplished -- links broken 
SEQ 
to.pipe ! link  bzk, sceurce-sdece 
otherwise --|@mres not breken, 
-- let link.rel loop again 
to.pipe ! link.rel; source; dest 


token = link.abt 
SEQ 
to.pipe®! linktabt; source; edect 
—-= "pass LO =ertGinate: 

get.current.tire “(o.cU, fronneieeeecmc 
Eromac¢ Ly~.SOUCEC, a SEC. Conn) 

get ..current.t ve" (ee-cU emaemn-cU, toc, 
fromec eweadese. GSt conn) 


continue := TRUE 
1-2 = 90 
WHILE ((1 < 16) AND continue) 
SEQ 
Le 


(((edge.a[i])=srce.conn) 
OR ((edge.b[{1])=srce.conn) ) 


SEO 
edge.ok[i] := FALSE 
continue := FALSE 
ferpipe ! BYTE (+220); byte. nia 
byte.nil 
otherwise 
i Sea ees 1] 


to.pipe ! link.rei; source; dest 

break.conn ({(to.c0, Promeeu, eo. cl, tr eomnc., 
source, dest, accomplished) 

make.conn (to G07 8renee07 eo el enone, 
source, dest, accomplished) 
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ie 


accomplished 
to.pipe ! link.ack; source; dest 
otherwise 
SEQ 
Some lpe = link, reqs source; dest 
reGeecme.;— creqrent + 1 


token = link.ack 
--consume rest of acknowledge packet 
SKIP 

token = link.brk 
—- msg cycled, consume 
SKIP 

token = link.rel 
--consume rest of acknowledge packet 
SKIP 

otherwise 
=— Pass lesen Lor Vesting andenonitoring 
to.pipe ! token; source; dest 


(Veq seni eno teams) —& Clock 7 APTER now PLUS delay 


SEO 
clock ? now 
req.cnt := 0 
edge.ok{edge.index] := TRUE 
to.pipe ! BYTE (edge.index+200); byte.nil; 
byte.nil 
edge.index := edge.index + 1 
Ds 
edge.index >= (edgeQ.ct + edge3.ct) 
edge.index := 0 
otherwise 


SKIP 
--mena Of Controller code 
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—_— o_O cm cm cc cr wc re cw cr cr rc we ce ww ws es es es ee ee ie ie i 
me ce ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee es ee ee ee ee es ees ee es es es es es es ees ee es es es es es es es es es ee es ee ee ee ee ee eee ee ee 


-- TRAM.CODE - code for each TRAM, performing work & 
-- requesting links 


a ee Om cc rc ce ee es es es es ee ee es ce ee es ies ee ees ee ie ee ieee i 
se... ee 


PROC tram.code (CHAN OF ANY to.pipe, from.pipe, 
linkO<in, ‘linkOeout einige nee Clee 
VAL INT slot.desig, no.trams) 


PROC link.manager (CHAN OF ANY to.pipe, from.pipe, 
mgr.to.agent0O, mgr.from.agent0O, 
mgr.to.agent3, mgr.from.agent3, 
mgr.from,user0, mgr. fbrom. users, 

CHAN OF INT mgr vGo.user0, mgr-to.usen.s, 
VAL INT slot.desig, no.trams) 


#USE © wetemee., jams 

FUSE “"Ctrlemacees ima 

#USE "“iantcmds.esm 

BYTE simak O7pleenies 

BYTE linkO@Memedseo, Tinkseeredere 

BYTE token, bytel, byte2, regq.source, req.dest 


-- index corresponds to slot  numberew =) (=leetor linkd 
= and W/ec0-so for links 
-- stored value is hardwired C004 link to linkO or 3 
VAL 11nk03.desig IS [2275 35 e oe ee er 
6, lOteecO eZ, ode les. 

12 aes, 26, “Seeeooeeoe, 

99, GO Zoe, wer 17; 

ZA; i 1, 20 ee 29, 

30, 11, 1332 eee 0. 


VAL INT buffer.size IS 3 : 
{fouffer.size-1]CHAN OF ANY b: 
{(buffer.size=2)] BYTE) ee eee! 

CHAN OF ANY to.buffer 

BYTE twin, S.1in, d.in, Seeeub es cut, womens 


PAR 
SEQ 
linkO := BYTE(1ink03.desig[slot.desig] ) 
link3 := BYTE(link03.desig[(slot.desig+20) }) 
linkO.tied.to := byte.nil 
1ink3.tied.to := bywecmadl 


bl 


WHILE TRUE 
ALT 
mgr.from.agentO ? token 
1) 
(token = done.with. link) 
tO. butteme: linkerewm 1ink0; 
PimieOme ted. to 
(token = failed) 
tO bad seme  Tink.abt; link0O; 
1ink0.tied.to 
(token = all.done) 
tO. butier |! BYTEYslot .desigt100); 
MWyeeenil; byte.nil 
((INT(token)) < 36) 
SEQ 
-- token is a link designation 
linkO.tied.to := 
BYTE (link03.desig[INT (token) ]) 
EOvouUErECreme Link.req; linkO; 


linkO.tied.to 
otherwise 


5h Le 


mgr.from.agent3 ? token 
Jie 
(token = done.with.link) 
LO. bDUfreiae whim. rei: link3; 
ipitnies. taeed. to 
(token = failed) 
mo.buttieme! Linksabt;> links; 
iMnks  tiedeto 
(token = all.done) 
EO. OMe rome: SY Treas lot .desigt120) ; 
bywesmll; byte.nil 
((INT (token)) < 36) 
SEQ 
-- token is a link designation 
link3.tied.to := 
BYTE (1ink03.desig[{INT (token) }) 
iherbuieeer 'weunikewreq; link3; 
liniem@eied.to 


otherwise 
SKIP 


from.pipe ? token; bytel; byte2 
ales: 
token = link.regq 
to.buffer ! token; bytel; byte2 
token = link.rel 
to.buffer ! token; bytel; bytez 
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token~—S linkyaek 
SEQ 
Te 
-- if local link involved, 


—< Inform userener xmit 
byte2 = 1link0O 
SEQ 
mgr.to.user0 ! user.linkmade 
byte2 := byte.nil 
byte2 = link3 
SEQ 
mgr.to.user3 ! user.linkmade 
byteZ :="bytevnil 
otherwise 
She 


10m 
-- if local link involved, 
-- INfOrmeuser to. xMLtE 
bytel = link0O 


SEQ 
mgr.tO.agent Ome 1 Ink-=made 
bytel := byte.nil 
bytel = link3 
SEQ 


mgr.to.agent3 ! link.made 
bytel := byte.nil 
otherwise 
SEE 


ibe 
((bytel=byte.nil) AND (byte2=byte.nil) ) 
SKIP -- consume 
otherwise 
to.buffer ! token; bytel; byte2 


token = link.brk 
Ce 
== if local links involved, 
= clear user status, consume 
bytel = link0O 
SEQ 
linkO.tied.tco 7= jyvte.nil 
mgr.to.agentO ! link.gone 
bytel = link3 
SEQ 


link3.tied.to := byte.nil 
mgr.to.agent3 ! link.gone 
otherwise 


-- pass on if not of local interest 
to.buffer ! token; bytel; byte2 


114 


token = link.abt 
BeaeSINGesOmuginatead by source, 
-— consume if this 1S source 


SEQ 
ieF 
((bytel = 1linkQ) OR (bytel = link3)) 
oONITP s-cConsume 
otherwise 
to.buffer ! token; bytel; byte2 
Le 


byte2 = linkd 

mgr.to.user0 ! user.failed 
byte2 = link3 

mgr.to.user3 ! user.failed 


otherwise 
SKIP 
token = link.rel 
SEO 
Lis 


stl ocal link involved, 
== inform user to xmit 
bytel = link0O 
SEO 
mgr.to.agent0O ! reinit 
bytel := byte.nil 
bytel = link3 
SEO 
mgr.to.agent3 ! reinit 
bytel := byte.nil 
otherwise 
SKIP 


igia 
== if loge link involved, 
-- inform user to xmit 
byte2 = link0 


SEQ 
mgr.to.user0 ! user.reinit 
byte2 := byte.nil 
byte2 = link3 
Sis 


mgr.to.user3 ! user.reinit 
byte2 := byte.nil 
otherwise 
Sine, 
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ee 
((bytel=byte.nil) AND (byte2=byte.nil) ) 
SKIP 
otherwise - 
to.buffer ! token; bytel; byte2 


otherwise 
== non-Cma byte, peass Jaen 
to.buffer ! token; bytel; byte2 


PAR 
WHILE TRUE 
SEQ 
to.buffer ? teaie es. in ea 
b[0] JG: ineisen women 
PAR 


PAR p = 0 FOR (Duttersscaze 7) 
WHEE TRUE 
SEQ 
Bip] 2 tee. S {Cl meen 
Diptl) See leiease peo ie 


WHILE TRUE 
SEQ 
bibuffer.size=2), ? seout; s.olm ) dJoue 
to.pipe™! Cleves cue, seanoue 
-- end of manager 


PROC agentQ (CHAN OF ANY mgr.to.agent0O, mgr.from.agent0O, 
agent0.to.userdQ, 
agentO.from.user0, linkO.out, 

VAL INT link.desig) 


#USH reunite 

#USE ““imimemeic. t Sis 

#USE "“billekei Zemiesr. 

#USE “faultime. wom 

VAL block.len IS INT (block.size) 
BYTE byte.in : 

[block. len] BYTE msg 

BOOL continue, aborted 

TIMER time.c 

INT now, check.time 
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SEQ 


agent0O.to.userQ ! ready.to.rcv 
continue := TRUE 
WHILE continue 
PRI ALT 
mgor.to,agent0 sambyte. im 
ip 
byte.in = link.made 
SEO 
msq{0O)] := BYTE(link.desig) 


-- repl dest w/ source 
time.c ? now 


check.time := now PLUS fault.time 
OutpuPOnhal) Ei laink® yout; msG,tame.c, 
check.time, aborted) 


Age: 
aborted 
SEO 
mgr.from.agentO ! failed 
mgr.to.agentO ? byte.in 
Reinitialise (link0O. out) 
otherwise 


mgr.from.agentO ! done.with.link 


byte.in = link.gone 
agentO.to.user0 ! ready.to.rcv 


otherwise 
SKIP 
agentO.from.user0 ? msg 
SEQ 
mgr.from.agentO ! msg([0] 
re 
msg{0] = all.done 
continue := FALSE 
otherwise 
oKIP 


-- end of agent0O 


Lg 


PROC userQ (CHAN OF ANY agent0O.to.user0, 
agentO.from.user0, mgr.from.user0O, link0O.in, 
CHAN OF IN? "mgr eteeusceno- 
VAL INT link.desig, no.trams) 


#USE reinit 

#USE snglmath 

#USE “intends eer - 
t{USE apie coueze. tor. 


-- user supplied values 

VAL block. len@MiS INT(block .size) 

(block. len] BYTE “data tout, datresin 

BYTE in.byte 

INT req.dest, counter, check.time,now, any.int, seedl6: 
BOOL continue, aborted, active 

INT32 seed 

REAL32 result 

TIMER time neyeme toe. 


PRIVEAR 
WHITES 
DEW 
mgr.to.user0 ? any.inte=——- Erigger Communicacionms 
LE 
any.int = user.linkmade 
SEO 


InputOrFail ic (itmk0 in, | dace ae 
mgr.to.user0Q, aborted) 


lala 
aborted 
SEO 
mgr.to.user0Q ? any.int 
gS 
any.int = user.reinit 
Reinitialise (link0O.in) 
otherwise 
SKIP 
otherwise 
SKIP -- data rcvd OK, use as desired 
any.int = user.reinit 


Reinitialise (link0O.in) 


otherwise 
SKIP 
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SNae. 


IF 
link.desig < no.trams 
SEQ 
continue := TRUE 
COUntwEeE:--=— © 
otherwise 
SEQ 
continue := FALSE 
counter := 10000 
clock ? seedl16 
seed := INT32(seedl16) 
--seed := INT32(link.desig*100) 
WHILE counter < 1000 
SEQ 
Soumecr == Counter + L 


-- generate data 
SEQ 1 = 1 FOR (block.len-1) 
data.oucg [i] := 100seYTE) 


=-Send tOvamy tank 0 or 3 
req.dest := link.desig 
WHILE ((req.dest = link.desig) OR 
((req.dest >= no.trams) AND 
(req.dest < 20)) OR 
(req.dest >= (no.trams+20) ) ) 
== for leak 0-0 CONEY! (commented out otherwise) 
--WHILE ((req.dest=link.desig) OR 
--(req.dest>=no.trams) ) 


SEQ 
result,seed := RAN(seed) 
req.dest := INT ROUND (result*31.0 (REAL32) ) 


-- put destination address in array at addr 0 
data.out[0}] := BYTE(req.dest) 

agent0O.to.user0 ? in.byte 

agentO.from.user0O ! data.out 


agent0O.to.user0 ? in.byte 


agentO.from.user0 ! all.done 
== end es wiser 
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PROC agent3 (CHAN OF ANY mgr.to.agent3, mgr.from.agent3, 
agent3.to.user3, 
agent3.from.user3, link3.out, 

VAL INT link.desig) 


#USE reinit 

TUSr “ime meses in. 

#USE "“blekSize.tsr" 

#USE “faultime.tsr"™ 

VAL block.len IS INT (block.size) 
BYTE Dyvee. iar: 

(block.len]BYTE msg 

BOOL continue, aborted 

TIMER time.c 

INT now, check.time 


SEO 
agents te.users ssready co.uev 
continue := TRUE 
WHILE continue 
PRIA 
NgGr.8On,agents  eepyte.im 
i 
byte.in = link.made 
ea) 
mSqlOl> 3= BYDE< tink desig) 


-- repl dest w/ source 
time.c ? now 
check.time := now PLUS fault.time 
OutputOrFail.t (lank3 cue meg, E1mese, 
check.time, aborted) 
LE 
aborted 
SEO 
mgr.from.agent3 ! failed 
mgr.to.agent3 ? byte.in 
Reinitialise (link3.out) 
otherwise 
mgr.from.agent3 ! done.with.link 


byte.in = link.gone 
agents .Ee-user3 ! "ready to. rev 


otherwise 
SKIP 
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agent3.from-usemem: “msg 


SEO 
mgr.from.agent3 ! msg[Q] 
13 
msg[0O]) = all.done 
continue := FALSE 
otherwise 
SKIP 


-- end of agent3 


PROC user3 (CHAN OF ANY agent3.to.user3, 
agents @sreom.user3s, magr.from.user3, link3.in, 
CHAN OF INT mgr.to.user3, 
VAL INT link.desig, no.trams) 


fUon rein 

#USE snglmath 

fos "“intemds.tsr" 
Hose “Olcksize.tsr” 


-- user supplied values 

VAL block.len IS INT (block.size) 

(block.len]BYTE data.out, data.in 

BYTE in.byte 

INT req.dest, counter, check.time,now, any.int, seedlé6: 
BOOL continue, aborted, active 

INT32 seed : 

REAL32 result 

hEMeER tLime.c, clock 


PRI PAR 
Vr Oise ee CRUE 
S180, 
Mgr. tesusenrs ~sanyemnt —-sirigger Communications 
te 
any.int = user.linkmade 


SEQ 
Inpucerpead!.c (limes lia, —data.in, 
mgr.to.user3, aborted) 
Es 
aborted 
SEQ 
maor.to.useese? any. int 
re 
any.int = user.reinit 


1 


Reinitialise (link3.in) 
otherwise 
SKIP 


otherwise 
SKIP -- data rcvd OK, use as desired 


anyeint = USer. 6a 
Reinitialise (link3.in) 


otherwise 
SKIP 
SEO 
ios 
link. désig Soe (iloet ralcua2”) 
SEO 
continue := TRUE 
counter := 0 
otherwise 
SEQ 
continue := FALSE 
counter := 10000 
clock ? seedl6 
seed := INT32 (seedl16) 
--seed :;= INT32( len desig 100) 
WHILE counter < 1000 
SEQ 
counter := counter + 1 


-- generate data 
SEQ i= 1 FOR (block.len-1) 
data.out[i]) := 100 (BYTE) 


—-- send togany fink 0) ores 

req.dest := link.desig 

WHILE ((req.dest = link.desig) OR 
((req.dest >= no.trams) AND 
(req.dest < 20)) OR 
(req.dest >= (no.trams+20) ) ) 


-= for link 3=330NEY!(commenemenir) 

--WHILE ((req.dest = link.desig) OR 
~-~(req.dest < 20) OR 
--(req.dest >= (no.trams+20) )) 


SEQ 
result,seed := RAN (seed) 
req.dest := INT ROUND (result*31.0 (REAL32) ) 


ize 


-- put destination address in array at addr 0 
datavout[O0)] := BYTE (req.dest) 


agent3.to.user3 ? in.byte 
agent3.from.user3 ! data.out 


agent Seo users 7 inebyte 
agent3.from.user3 ! all.done 
ameend Of .user3 


-- internal channels between users and manager 
CHAN OF ANY mgr.to.agent0O, mgr.from.agentdO, 
mgr.to.agent3, mgr.from.agent3, 
mgr.from.user0O, mgr.from.user3, 
agent0O.to.user0, agent3.to.user3, 
agent0O.from.user0, agent3.from.user3 
CAeteOr INT mgr.to.user0, mgr.to.user3 


PRI PAR 
PAR 
link.manager (to.pipe, from.pipe, 

Mer .eo.agent0, mgr.from,agentO, 
mop eo.,agents, mgr.from.agent3, 
Mmqgryierom,user0,.mgr.from.users, 
Ndr. cO.vcepe; mar. cO.USeCr 3S, 
Slot.desig, no.trams) 


agentO (mgr.to.agent0O, mgr.from.agent0Q, 
agent0O.to.user0, agent0O.from.user0O, 
Limmwomoue, slot.desig) 


agent3 (mgr.to.agent3, mgr.from.agent3, 
agent3.to.user3, agent3.from.user3, 
link3.out, slot.desig+20) 


PAR 
user0Q (agentO.to.user0, agentO.from.user0Q, 
mgr.from.user0O, link0O.in, 
MGEpeoeusersu, SlOt.desagq, no.trams) 


user3 (agent3.to.user3, agent3.from.user3, 
Wa. FErOom.usersy .1 inks" in, 
mgr.to.user3, sSlot.desig+20, no.trams) 
—Sfonge Of 1TRAM.CODE 
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-- Placed Pars (Controller -> T212, TramCode -> T800’s) 
-- Global Declarations, Constants and Placed Pars 


FUSE “links<s isre 


— — — = — = —= — — — — — — — — — — — — — — — — — — — —_— — — 
i Oc Oc O™ cs ™ OO cr © cs ™ ce ™ cee ™@® ce ™@™ ce ™@® oe ™@ oe ™@™ ce @ coe @™ coe @™ ce ™@™ ce @ coe ™@™ oe @™ coe ™ co @ Ce OO  O™ LC® ClCU™@® CL CU™ 


-- control info passing pilpew@btw TZ2Z02yamee td rams 
[no.trams+2]CHAN OF ANY pipe 


-- links btw 17212 "and Co04ds 
CHAN OB@ANY €2Zeteece stZ from.cu, 
t2 Os el wtE2 frome 


-- litt make protocol, form) cucu cae 

-- data xfer channels between all Trams (via C004’s) 

[no.trams]CHAN OF ANY ilinkO.toe,cO, eek) -trem-c!, 
link3@eco. clarinet om, cO 


PLACED PAR 
PROCESSOR no.trams T2 


PLACE pipe[0] AT link2in 
PLACE pipe[no.trams+1] AT linklout 
PLACE. €2 stone. AT linkOout 
PLACE t2Z3f£romaceo AY ieenk 0 in 
PLACE "GZ me .eul ATS nk Sout 
PLACE "Zt comme | AY Vank3in 


controller (pipe), pipe[noseeams+!], 
C2,.00.Cc07 a2. paeme cur 
CZxtovieie=s 2 .from.ce enone amey 


PLACED PAR slot = 0 FOR (no.trams) 


PROCESSOR, ((S1 eri 1 00}mei se 


PLACE pipe[slot] AY Pik Koute 
PLACE pipe[slot+1] AT te 1.) 
PLACE linkO. from euiciet | AY dankoamn 
PLACE linkOv temo is ter Ma aia eenbhe 
PLACE lLiInk3Jiromoeons ver yy age Salil 
PLACE links tome ister AT link3out 


tram.code (pipe(sict)]pepipe ster aa), 
LinkO=E£romuacel s lomo Omtenc) (silierel: 
link3. from .cO (slot ums me. cl islotl, 
slot, no.trams) 
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APPENDIX B 
MESSAGE EXCHANGE TEST CODE FOR B004 


—— cc ee ee ee ee ee es ee ee ee es es es ee es ee ee ee ee ee ce es ce ce ce ce ce ee es ee ee ee ee ee eee eee ae ee 
ce cc cc cr cr cr crc cr crc cr cr cr cm cr cr cr cr cr cr cc crc cr cc cr cmc cr cc cc cc ce es ee ee ee ee ee ee eee 


pee IMER - code for BO04 Timer of BOl2 activity in MSGX 
-- Operating on B004 Evaluation Board 


#USE userio 
#USE “links.tsr" -- transputer link defns 
“Woe “bicksize.tsr" -~ data block size for ref 


—_—em Ss ae ee ee eee oie eee eee ame cee cee ame ame cee ce ame cee eee ae eee eee eee eee eee eee eee cee cee eee cee cee eee eee cee eee cee cee cee cee cee cee cee cee oe cme cee cee ame acme em ame em ame em ame es a 


Pa Ne OPeANY Up.in, Wp.cout, ecno.to.buffer 


pao place links 
PLACE up.in IND stay 7Aa biol 
PEACE up.out AT link3out 


PROC timer (CHAN OF INT keyboard, 
CHAN OF ANY screen, up.in, up.out, 
VAL INT no.trams) 


fiom 'intemas.tsr"™ 


VAL terminate IS 199 (BYTE): -- shuts down buffer procs 
BYTE command.byte, bytel, byte2 

BOO more ; 

DIMER clock 

f7 iit TINT counter & -- various command counters 


fou Ni totale grand 

[36] INT user.done 

INT key.in, done.count, sum, sumtot, grandtot 
INT start, stop, elapsed, slot.temp 


-- main code for B004 monitor - TIMER 


me we i we i aw i i Oc Oi ws 2S ws = es SS SZ. 02822 2 | = SK - - OSC LE Pe SS TF = 


SEO 

=oeeihedia! tae Loge 

more := TRUE 

done.count := 0 

sumtot := 0 

Geandtg: >— 0 

SEQ 1= 0 FOR 36 
user.done[i]}] := 0 

SEOutmr— 70 FOR 37 
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SEQ 3. = BR eKe 
COuUnte r= | seine —ae 
SEQ i= 0 FOR 6 
SEQ 
Cota lr) 
grand[i] 
Clock 2 Stage 
write.int (screen, start,12) 
newline (screen) 


0 
0 


WHLGE Mone 
PRI ALT 
up.in ? command. byte, 9 byeeW wey eeZ 
IF 
(( (INT (command.byte)) > (39)) AND 
((INT (command.byte)) < (46))) 
Se) 
-- command byte, get next two parameters 
up.out ! command.byte; bytel; byte2 
-- update appropriate command counter 
counter [to.slot [ iINEtevyecel 
[ (INT (command.byte))-40] := 
counter([to.slot [INT (bytel) ] ] 
[ (INT (command.byte))-40] + 1 


(( (INT (command.byte)) > (99)) AND 
(CINT (command. byte) ) == (7) 
-- a tram has sent a notice it is done xmit 
SOO! 
Clocks] slots aemp 
user.done[ ((INT(command.byte))-100)] := 
((slot.temp-start) *64) /1000 


done -count := done ,coune tet 
Jug 
done.count = (no.trams * 2) 
SEQ 


write.full.string(screen, 
"Test Complete!") 
newline (screen) 
Ccloece 2 Stop 
elapsed := ((stop-start) *64) /1000 
write.full.string(screen, 
"Elapsed Time: ") 
write.int(screen, elapsed, 12) 
write.full.string(screen, 
au Block Size oa) 
write.int(screen, INT(block.size),12) 


otherwise 
SKIP 
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otherwise 


SEQ 
SKIP 
keyboard ? key.in 
SEQ 
-~- handle keyboard inputs 
IQ); 
(kKey.inm —=me lyme Oke (keyein = a13) -- "OO": quit 
SEO 
more := FALSE 
up.out ! terminate; terminate; terminate 
(key.in = 80) OR (key.in = 112) -- "PP": pause 
SEQ 


newline (screen) 
write.full.string(screen,"press any key.") 
keyboard ? key.in 


(key.in = 82) OR (key.in = 114) 
== “R": weesend a byte 
QWomeout !' BYTE (60) 


(key.in = 83) OR (key.in = 115) 
-- "S": show summary 
SEQ 
newline (screen) 
newline (screen) 
sumtot := 0 
grandtot := 0 
WEIGe full. Sstringmecreen, " 2) 
write.full.string(screen, 
Mabink . reg link.ack haliet meng) cn) 
wWhtewtull.stwang(screen, 
link. abt bee rea. “) 
newline (screen) 


SEQ 1 = 0 FOR: 6 


SEQ 
grand[i] := 0 
total[{i] := 0 
SEQ i= 0 FOR no.trams 
SEQ 


write.int (screen, i, 6) 
write.int (screen, counter[i][{0],12) 
write.int (screen, counter([i][{1],12) 
write.int (screen, counter[1i][3],12) 
write.int (screen, counter[i] [4],12) 
write.int (screen, counter([i][5],12) 
write.int (screen, user.done[i],12) 
newline (screen) 
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SEQ j = 
SEQ 


write. 
write. 
write. 
write. 
write. 
write. 
write. 


0 POR s6 


total[j):=total[j]+counter[i) [3] 
grand[j]:=grand[j]+counter[i] [Jj] 
sumtot := sumtot + counter([a|/[ 9) 
grandtot:=grandtot+counter [i] [Jj] 


fuIM, string{screena'loeea lis) 
int (screen, total[0],12) 

int (screen, total[1],12) 

int (screen, total[3],12) 

int (screen, total[4],12) 

int (screen, Eotaliloi'Z) 

int (screen, sumtot, 12) 


newline (screen) 
newline (screen) 


Sumtot := 0 

SEQ 1 = 0 FOR 6 
total (asim = =20 

SEQ 1 = 20 FOR no.trams 
Sv6 


write.int (screen,i, 6) 


write. 
write. 
.int (screen, counwer [i] {35 12) 
write. 
inttsereen, counter (1) [aie 
write. 


write 


write 


ine(screen, coumeer [1] [(0)],12) 
inwtscreen, counter (i) | PiyetZ) 


int (screen, counter[i][4],12) 


int (screen, user.done[i],12) 


newline (screen) 


SEQ j 
SEQ 


= 0 FOR 6 


write. 
write. 
write. 
write. 
write. 
write. 
write. 
Sumtot 


total[j]):=total[j)]+counter[i] [j] 
grand[j]:=grand[j]+counter[i]J [j] 
sumtot := sumtot + counter([ij [Jj] 
grandtot:=grandtot+counter[i)j [Jj] 


full stewng(seneen, “Totals"™) 
int (screen, total[0],12) 

int (screen, total[1],12) 

int (screen,total[3],12) 

int (screen, total[4],12) 

int (screen, total[5],12) 

int (screen, sumtot,12) 

>= 0 


newline (screen) 
newline (screen) 


write. 
write. 
write. 
write. 


full.string(screen, "Grands") 
int (screen, grand[0],12) 
int (screen, grand[1],12) 
int (screen, grand[3],12) 
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write.int (screen, grand[4],12) 
write.int (screen, grand[5],12) 
write.int (screen, grandtot, 12) 


otherwise =-——- any key, igmored 


© hone 
a) CC emma | E Mis 


PROC buffer (CHAN OF ANY into.buffer, outof.buffer) 


WAL INT bufferasize IS 3 
EPRibmeein, S.inee d.in, t.out, 
[buffer.size-1]CHAN OF ANY b: 
fbutter.size-Z2)BYTH t, s, d: 
[buffer.size-2]BOOL buffer.on 
BOOEy first. butffer.on, last.buffer.on 
VAL terminate IS 199 (BYTE): 

VAL BOOL otherwise IS TRUE: 


S Oley c. Out 


PAR 
SEQ 
first.buffer.on := TRUE 
WHEEE first buffer. on 
SO} 
mieOeblmtrer 2 t.in; Sian dian 
Eno! Jo bain: Ss.in; din 
1s 
t.in = terminate 
first.buffer.on := FALSE 
otherwise 
SKIP 
PAR -- replicated PAR to desired buffer size 
PAR p = 0 FOR (buffer.size-2) 
SEQ 
buffer.on[p] := TRUE 
WHILE buffer.on([p] 
SEQ 


Pipi elplzesip), dip) 
Mie tlpl, Steir dip) 
TE 
t[{p] = terminate 
buffer.on[p] := FALSE 
otherwise 
SKIP 
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SEQ 


last .buffer.on ==) 2RUE 
WHILE last.buffer.on 
SEQ 


b(buffer.size-2]" 2 t out; §seour, se eoeour 
outof,buffer ! flout; Ss. our, cece 
IF 
t.out = terminate 
last. buffer.on := FALSE 
otherwise 
SKIP 
—= €nd of DULf&esr 


PROC buffer (CHAN OF ANY into.buffer, outof.bpuffer) 


VAL INT buffer .sizensisa 

BYTE byte.in, bytesouce: 
[buffer.size-1]CHAN OF ANY b: 
[obuffer.size-Z] BYE Syeesnoe ra 
[buffer.size-2]BOOL buffer.on : 

BOOL first .buffer -on tact ol ere mon 
VAL terminate IS 199 (BYTE): 

VAL BOOL otherwise IS TRUE: 


PAR 
SEQ 
first.buffer .ony se leus 
WHILE first .burreuon 
SE 
into. buffer 7apy ees 
B(O0] ) byeewan 
IF 
byte.in = terminate 
first. bufferson =: — sr aioe 
otherwise 
SKIP 
PAR 
PAR p = 0 FOR (buffer.size-2) 
SHO. 
buffer.on[{p]) := TRUE 
WHILE buffer.on{[p] 
S/O 
b(p] ? byte.hold([p] 
D( pti] ebyte saree) (a 
Ee 
byte.hold[({p] = terminate 
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burEer emp] >= FALSE 
otherwise 
SKIP 


SRO) 
lastebutiiier son» : =eiRUE 
WHILE last.buffer.on 
SEQ 
Db (butter. size-Z] ? byte.out 
cleo. bukit erie byte . out 


Zi Fh 
byte.out = terminate 
last.buffer.on := FALSE 
otherwise 
SKIP 


—— —eEngeron Duftern 
PAR 


timer (keyboard, screen, up.in, echo.to.buffer, no.trams) 
buffer (echo.to.buffer, up.out) 
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APPENDIX C 
MESSAGE EXCHANGE ACTIVITY DISPLAY 


emcee as es ccc ces i cc ce ee cc cc ce cc cm i cr cr i ee ce es ee ee ee ee ee ee ie 
mm cematnt> emma came GND cumntnte seme ammenities, ent eminent cece cee ets eam Gets ees tts ce ce ce ee i ee ce i ee ee ee ee ee ee ee ee 


-— STATUSdb = BOOQ4 Status of BUlZ acti ie sree. 
-- To display activity of message exchange 


es es es ws ws i er ec cc cc i i ee ee ee ee ee es es es es ee ce ee es ss es es es a ee ee ee 
ee ee ee ee ee ee ee ee ee es es ce ee ee ee ee ee ee ee ee ee ee ee ee ee es eo es es es es es ees es es es es es es ee ee ee eo ee eo eee eee 


#USE userio 
#USE “Links.tsica 


CHAN OF ANY up.dm, Up. out, "“Choeto-puttenm 
buffer.to.echo, shut.down 


-- place links to intercept link control pipe commands 


PLACE up.in AT link2in 
PLACE up.out AT link3o0ut 
-- BUFFER.IN -- variable buffer on pipe before status 


-- allows B012 to process pipe w/o backup 


PROC buffer.in (CHAN OF ANY into. eutter, ouronsoumnem 


shutdown) 
CHAN OF ANY to.buffer 
VAL ENE buffer ssi76 sero 5.: -- number of buffer stages 
BYTE DYte Jan, byte OuUG Ey ee- sa 
[buffer.size-1]CHAN OF ANY b: -- array of channels 
(buffer.size-2)BYTE byte.hold :-- array of command bytes 
[buffer.size-2]BOOL buffer.on :-- array for shutdown 


BOOL first .butter.on, last buEter .onm, ssmuedownayoct Ive 
VAL terminate IS 199 (BYTE): -- constant for shutdown 
VAL BOOL otherwise IS TRUE: 


PAR 
-- get next input from BOlZ2 or from BO004 for shumeouwn 
PAR 
SEQ 
Shutdown.active := TRUE 
WHILE shutdown.active 
ALT 
shutdown ? byte.sd 
SEO 
to.buffer ! byte.sd 
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Shutdown.active := FALSE 
into.buffer ? byte.sd 
Cop bukter we! bytetsd 


-- place either in first buffer space, 
--terminate process if shutdown 


Say. 
first.buffer.on := TRUE 
WHILE first.buffer.on 
SEQ 


fo wouter: wavyle. in 
b{0} ! byte.in 
ee 


byte.in = terminate 
first esurter: orn: =F ALS 
otherwise 
SK DP 
-- replicated PAR for multi stage buffer. 
--Each terminated upon shutdown 
PAR 
PAR p = 0 FOR (buffer.size-2) 
SEQ 
buUrker. on |p) Gs— LRUE 
WHILE buffer.on([p] 
SHO) 
Sietee syte-noldip] 
Dively oyte. hola] 
bE 
byte.hold[{p] = terminate 
buffer.on[p] := FALSE 
otherwise 
SKIP 


-- final buffer stage for delivery to STATUS process 
SEQ 
last .buffer.on := TRUE 
WHILE last.buffer.on 
SHe 
Piswtier.siuze-2)? byte.out 
Scucot.burrer ! byte.out 


IF 
byte.out = terminate 
last.buffer.on := FALSE 
otherwise 
SKIP 


-= @6nd om burfer,. in 
PROC statusdb (CHAN OF INT keyboard, 


CHAN OF ANY screen, up.in, up.out, shutdown, 
VAL INT no.trams) 


3 


*USE “inteecmdsecsms 


#USE “etrlemadsJise. 
VAL terminate IS 199 “(Baia 
BYTE command.byte, bytel, byte2, link.byte 


BOOL more, 
TIMER clock 
{17] INT num.used 
{37] [6] INT counter 
{[6]INT total meuvand 
[36] INT user.done 


send.quit 


array for # of links 
array for # of commands 
totals and subtotals 
track TRAM USER done 


INT 
INT 
INT 
INT 
INT 


SUM, SUMEOE, Borandeoe 
num.reqs, num.brks, num.abts, num.reis 
line.num, XPOS.inG, aSCieme mo eis cm 

Tlinkl, linkZaeinks. used 
Start, stop, elapsed, delay, 


key.in, done.count, 


num. acksS, 


now 


-- translate Input byee fremeey rs 

== to english quivelanmt. for displ ay 

PROC xlate.byte (CHAN OF ANY screen, 
VAL INT xpos) 


VAL BYTE x.byte, 


Tintemdseest | 
“CELrILEmMas rs. 


#USE 
#USE 
SEQ 
goto.xy (screen, xpos, 0) 
Je 

-- bytes 0-31 passed correspond to C004 link nos. 
x.byte = (BYTE 0) 
write. fu lam string 
x.byte = (BYTE 1) 
write, full struing 

x. byte = (BYTE 2) 
Weite.f£UL1L, Strang 

x. byte = (BYTE 3) 
write.full.string 

x. byte = (BYTE 4) 
write.full.string 
x.byte = (BYTE 5) 
write.full.string 

x. byte = (BYTE 6) 
Write. full .steune 
SDV = eS ire a) 
Wreiee.riuslestring 

x. byte = (BYTE 8) 
weate. ful]. stranc 

x. byte = (BYTE 9) 
writeeeul ls sering 
x.byte = (BYTE 10) 


(screen, "“-Slot 2 Link 3 ") 


(screen, "-Slot 5 Link 3 ") 


(screen, "-Slot 1 Link 3 ") 


(screen, “=Siet 5S Limi. =) 


(screen, "-Slot 2 Link 0 ") 


(screen, “-Slot 1 Link 0 ") 


(screen, "-Slot 6 Link 0 ") 


(screen, "-Slot 6 Link 3 ") 


(screen, "-Slot 15 Link 0 ") 


(sereen, “golem so Link 0%) 


134 


write.full sstring 
x. byte = (BYTE 11) 
Wi ltheet Udel ast rang 
Xxepyte = (BYRE) 12) 
writes fade. string 
x. byte = (BYTE 13) 
Write hull: string 
x. byte = (BYTE 14) 
write. ta) losering 
x. byte = (BYTE 15) 
write.full.string 
x. byte = (BYTE 16) 
Weree. ful ost ring 
x. byte = (BYTE 17) 
write.full.string 
x. byte = (BYTE 18) 
WEES, fuel, StTLAING 
x. byte = (BYTE 19) 
Windies Puli Stee mag 
x. byte = (BYTE 20) 
write.full.string 
x. byte = (BYTE 21) 
write.full.string 
x. byte = (BYTE 22) 
write. full.string 
x.byte = (BYTE 23) 
Wire 1 Ceeeiaalel . Sieas ng 
x. byte = (BYTE 24) 
write.full.string 
x.byte = (BYTE 25) 
Wreiteaiall | sString 
xX. byte =, (BYTE 26) 
Wer temrulel, slrImngG 
Pby ten — a(BY TE 27) 
write.full.string 
x. byte = (BYTE 28) 
Rpeage= — (Cb Mls sis aeh eyo: 
x. byte = (BYTE 29) 
write sful@ostrpeng 
x. byte = (BYTE 30) 
write.full.string 
x. byte = (BYTE 31) 
write.full.string 


(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 
(screen, 


(screen, 


"=s=S lot 15 


r=Sl Ot wie 
Paelot 12 
Peo Lot. 1 
moot. 8 
Bo LO. 
‘Ssnnoc - 7 
ao LOtms 3S 
wo hot 4 
aS Ott 3 
Ot 7 
"=Slet 4 
Mo Loe 0 
fo rota ed 
b=5 1 Otel 4 
eS SOt ele 
SS Ot. pa 
plot 13 
cea ol bs 012s, 
YS Lot esd 
N=SLOt wix0 


"—Slot 10 


Link 
gas K 
Louies 
Link 
Link 
emer 
Link 
ask 
Link 
mink 
Link 
Link 
Link 
Link 
Link 
Link 
aK. 
Link 
Link 
Link 
Link 


Dink 


3 
0 


ae 
ot) 


—-- translation for link control commands and NIL 


x.byte = byte.nil 
write.full.string 
x. byte = link.ack 
write.full.string 
x.byte = link.rel 
write.full.string 
x.byte = link.reg 


(screen, 
(screen, 


(screen, 
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"-Nil Byte 
"—-link.ack 


"—-link.rel 


_) 
~) 
a) 


write. full.strinem@(screen,, “=)inmeneg ) 
x. byte = link.brk 


write.full.strinemitscreen,” *-=link 9emn nv) 
x. byte = link.abt 

write.full.string® (screen, —lank ape a) 
x. byte = link.rei 

write.full.string (screen, "-link.rei ) 


-- miscellaneous signals used in control & testing 
x.byte = failed 


write.full.string (Screen, "-failed a) 
x.byte = reinit 

write.full.string (screen, "-reinit =) 
x. byte = done.with.link 

write.full.string (screen, “-done.with. link —") 
x. byte = all.done 

write.full.string (screen, "-all.done m) 
x.byte = ready.to.rcv 

write.full.string (Sereen, -reaGy-boete, ~) 
x.byte = link.made 

write.full.string (screen, "“"-link.made =) 
x. byte = link.gone 

write.full.string (screen, "-link.gone w) 
x.byte = (BYTE 199) 

write.full.string (screen, “-terminated echo ") 


-- display TRAM DONE notices when received 
(( (x. byte) >(BYTE(99))) AND ((x.byte) <(BYTE(136) ))) 
Seo 
goto.xy (screen, 0,17) 
write.full.string (sereen,, wan.) 
write.int (screen, (INT (x.byte))-100, 3) 
write.full.string (screen aoone s 
newline (screen) 


-- display BAD EDGE notices when received 


(( (x. byte) >(BYTE(199))) AND (Gc 2bvce) <(emeE (216) 
SEQ 
goto.xy (screen, 20, 20) 
write.full.string (screen, “=Edge") 
write.int (screen, (INT(x.byte) )-200, 3) 
write.full.string (screen, " bad Bo) 


newline (screen) 


otherwise 
-- if unknown byte not successfully translated 
SEQ 
goto.xy (screen, 20,18) 
write.full.string(screen, "==UNKNOWN BYTE== a) 
write.int (screen, INT(x.byte), 6) 


-- end of xlate byte 
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-- PROC handle.screen -- for repeated screen 
oan updates for various commands recieved 
PROC handle.screen (VAL BYTE link.byte, 
VoeerNt Vinkl, link2, dni, in2) 


SEQ 
mC loce eNeme ost byte On Screen WsouUrec) 
VS! 

ak 1 =< l6 mca link 30 
SEQ 
line.num 
OOS Rie 
otherwise -- a link 3 
SEQ 
line.num 
xpos.inc 


Baul 


ott 
on) 


ing 
20 


Gouo.xvyacerecememe inkl —=xpos.i1ne)*3) +14, line.num) 
write.char (screen, link.byte) 


-- place the second byte on screen (destination) 


ee 
lamk2 <= 446 -- a link 0 
SEQ 
line.num := lnl 
XOOS = iniGew- — 90 
otherwise -- a link 3 
SEQ 
line.num := 1n2 
XDOsmimer .— 20 


GOLO. xy (Sereen lank poserne ys) +14, line.num) 
write.char (screen, link.byte) 
-- end of handle.screen 


-- main code for B004 monitor 


SEQ 
-- initialize loop 
-- initialize all counters used 
num.acks 
num.reqs 
num. orks 
num.abts 
num.reis 
more := TRUE 
done.count 
links.used 


now ou tl 
QOoo°oo 


oil 
© 


ley 


SEQ 1 = 0 FOR 36 
user.done[{i] := 0 

delay := 32768 

SEQ 1 = 0 FOR 17 
num.used{i] := 0 


~- initialize display format 
SEQ 1 = 0 FOR 20 

newline (screen) 
goto. xy (screen, 0,1) 
write.full.string(screen, "Slot Desig eee > eee 
write.full.string(screen, 

"EF G H IT eo) KL MeN coe 
newline (screen) 
write.full.string(screen, "Slot # ee 
SEQ 1 = 0 FOR 16 

write. int (sereen a op 


-—- intitiallize @ilcplay celhunmnc 

newline (screen) 

newline (screen) 
write.full.string (screen, “Ernk 0) Reon.) 
newline (screen) 

write. full. string (sereen,  brnk Sehten 
newline (screen) 

newline (screen) 

write. full.string (screen, “ink Aer. | 
newline (screen) 
write.full. stung (sereen, “Link 32AGh 
newline (screen) 

newline (screen) 
write.full.string(screen, "Link 0 BRK :") 
newline (screen) 

write.full.string (SereenmelLinks seer 
newline (screen) 

newline (screen) 
write.full.string (screen, “Link sO sae ie 
newline (screen) 
write.full.string(screen, "Link 3 ABT :") 
newline (screen) 

newline (screen) 
write.full.string(screen, "Link 0 REI :") 
newline (screen) 
write.full.string(screen, "Link 3 REI :") 


-- initialize edge status display 
goto.xy(screen,0Q,21) 
write.full.string(screen, "Edge # 8%) 
SEQ 1. = 0 FOR 16 

write.int (screen,1i, 3) 
newline (screen) 
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Goto. xy (scréenmts, 22) 
SEQ i = 0 FOR 16 
write.full.stwing(sereen, +") 


-- initialize # of edges used display 
goto.xy (screen, 64, 0) 
write.full.strine (screen, +Used. Count") 
SEQ 1 = 1 FOR 16 
See 
goto.xy (screen, 65,1) 
write.int (screen,i, 3) 


WHILE more 
SEO 
up.in ? command.byte == GCG mexe byte in pipe 
IF 
-- take appropriate display and counter action 
-- for each command received from BO12 
(( (INT (command.byte)) > (39)) AND 
((INT(command.byte)) < (46))) 
SEQ 
-- command byte, get next two parameters 
up.in ? bytel; byte2 
up.out ! command.byte; bytel; byte2 
counter[to.slot [INT (bytel) ]] 
[ (INT (command.byte))-40] := 
eCountermiee. Slop i mnt (byte!) )] 
[ (INT (command.byte))-40] + 1 


xlate.byte (screen, command.byte, 0) 
xlate.byte (screen, bytel,15) 
xlate. byte (screen, byte2, 35) 


-- determine characters used on screen for 
== display of source & dest 


iB 
(CIMIMbYtel) ) <eas2) 
itiQGine—ston.Sslot [INT i(bytel) ] 
otherwise 
Jk bs — 0 
IF 
((INT (byte2)) < 32) 
limi cee— tLOPSLOe LING (byte?) |] 
otherwise 
lark 2. := 250 
GE 
linkl < 16 
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Iss 


link.byte := BYTE (link1 +66) 
otherwise 
link. byte := BYTE (ier? 


command.byte = link.req 
SEQ 


handle.screen (link. byte, 1linkl, 
Link2..4 5) 

num.reqs := num.reqs + 1 

goto.xy(screen, 4,6) 

write.int (screen,num.reqs, 8) 


command.byte = link.ack 
SEQ 


handle.screen(link.byte,linkl, 
ME eV el net) 
num.acks := num.acks + 1 
goto.xy(screen, 4,9) 
write.int (screen,num.acks, 8) 
links.used := links.used + 1 
num.used[links.used] := 
num.used[{links.used] + 1 
goto. xy (screen, 70, links.used) 
write.int (screen, 
num.used[{links.used], 6) 


command.byte = link.brk 
SEQ 


handle.screen(link.byte,linkl, 
Wahjole Z sO at ay 

handle.screen (45 (BYTE), 1linkl, 
linkZe- 3) 

num. brkSS=Snuneaeks el 

goto.xy(screen, 4,12) 

write.int (screen,num.brks, 8) 

links.used := links.used - 1 


command.byte = link.abt 
SEQ 


handle.screen(link.byte,linkl, 

Link2. 13,14) 
handle.screen(63(BYTE) , link1, link2, 7,8) 
links.used := links.used - 1 
num.abts := num.abts + 1 
goto.xy(screen, 4,15) 
write.int (screen,num.abts, 8) 
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command.byte = link.rel 
SEQ 
handle.screen(link.byte,linkl, 
leeemes, 16, 17) 
bangle, semeen so by IE), lainkl,link2, 7,8) 
num.reis := num.reis + 1 
goto.xy(screen, 4,18) 
write.int (screen, num.abts, 8) 


otherwise -- including link.rel’s 
SKIP 


-- handle various user keystrokes for 
Ta stepping speed, pause, etc. 
clock ? now 
PRI ALT 
keyboard ? key.in 
IF 
(key.in = 81) OR (key.in = 113) 
eee Oats Quit 
SEC 
send.quit := TRUE 
more := FALSE 
Shutdown ! terminate 


(key.in = 43) 


=e SK Paster 

delay := delay / 2 
(key.in = 45) 

-- "-" = slower 

delay := delay * 2 


(key.in = 82) OR (key.in = 114) 
-- “"R": resend a byte 
Up some) BYTE G60) 


otherwise 
send.quit := FALSE 


clock ? AFTER now PLUS (delay * 100) 
SKIP 


-- handle TRAM (USER) DONE notices 
(((INT(command.byte)) > (99)) AND 
((INT(command.byte)) < (116))) 
-- a tram has sent a notice it is done 
-- xmitting on link0&3 
SEQ 


14] 


goto.xy (screen, 13+(( (INT (command.byte) )- 
100) 4.3) Fea) 
write.char (screen, 2 (BYTE) ) 


(( (INT (command.byte)) > (119)) AND 
(( INT (Command .byte)) <s¢ese)) ) 
-- a tram has sent a notice it is done 
= xmitting on 1ink0Q&3 
SEQ 
goto. xy (screen, 13+(( (INT (command.byte) )- 
ZO) <3) 7s) 
write.char (screen, 2 (BYTE) ) 


-- handle EDGE BAD info fren a2 lZeivaa Input ote 
(( (INT (command.byte)) > (199)) AND 

((INT (command.byte)) < (216))) 

-- an edge status has changed to GOOD 


SEQ 
goto. xy (screen, 14+(( (INT (command.byte) )- 
ZUG} 3)0, 22) 
write.char(screen,43(BYTE)) -- change to "+" 


(( (INT (command.byte)) > (219)) AND 
((INT(command.byte)) < (236))) 
-- an edge status has changed to BAD 
SEO 
goto.xy (screen, 14+(( (INT (command.byte) ) - 
Zeus) , 22) 


write. char (screen, 45(BYIE)) —-- change £o) =. 
otherwise 
-- handle unknown bytes received (for testing) 
SEQ 
We 


command.byte = terminate 
up.out ! terminate 

otherwise 
xlate.byte (screen, command.byte, 0) 


-- terminate all processes in this monitoring program, 
-- including all replicated PARs used in buffers 
Ee 
send.quit = TRUE 
SEQ -- flush queues 
WHILE (command.byte <> terminate) 
up.in ? command.byte 
up.out ! terminate 
otherwise 
SKIP 
-=  end@wer es) 04eMecn ter 
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Faeoc bufrer.cotie (CHAN OF ANY into.buffer, outof.buffer) 


VAL INT buffer.size IS 3 

Pers bYtCe.1nv™byee- out : 
[buffer.size-1]JCHAN OF ANY Db: 
[buffer.size-2]JBYTE byte.hold 
[puffer.size-2]BOOL buffer.on 

BOO ftirst.burfer.on, last.buffer.on 
VAL terminate IS 199 (BYTE): 

VAL BOOL otherwise IS TRUE: 


PAR 
SEQ 
first.buffer.on := TRUE 
WHILE first.buffer.on 
SEQ 
into.buffer ? byte.in 
b(0O}) ! byte.in 
103 
byte.in = terminate 
fi VSesburrer.on. *= FALSE 
otherwise 
SKIP 
PAR 
PAR p = 0 FOR (buffer.size-2) 
SEQ 
buffer.on[p] := TRUE 
WHILE buffer.on[p] 
SEQ 
b(p] ? byte.hold[p] 
Pipi. ! byteryhoeld[p] 
30) 
byte.hold[p] = terminate 
buffer.on[p] := FALSE 
otherwise 
Sy ILS 


SEO 
last .buffer.on := TRUE 
WHILE last.buffer.on 
SEQ 
b(buffer.size-2] ? byte.out 
outof.buffer ! byte.out 
IF 
byte.out = terminate 
last.buffer.on := FALSE 
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otherwise 
SKIP 
-- end of butter cure 


PAR 
buffer.in({up.an, buffer. to. 6ccno sme. een, 
statusdb (keyboard, screen, buffer.to.echo, 
echo.to.buffer, shut .down ne trams) 
buffer.out (echo.to.buffer, up.out) 
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